Sender: joeuser@isp.com From: joeuser@yahoo.com To: janeuser@otherisp.com
From is the author of the message - Sender is the agent which is transferring the message.
i.e. a message can be From the CEO, while the Sender is the administrative assistant.
The upside on this approach is that it avoids mucking with Reply-To, which is something that can cause problems for some (mailing lists don't always like it)
I don't think this simplifies UI coding enough for people to consider switching. I may be confounded by the verbosity of the spec though.
For example: is it really necessary to specify the skin on every element? All those XLINKs should default to sensible values unless I want the controls all to be purple for some reason, in which case I can understand the need to be verbose.
CSS is a great tool for tweaking the look of something. Could you not leverage that? stateHover and the like are re-inventing stuff that CSS already does.
I like the way list and menu elements are defined, although it may be overkill for most uses (having just an ID for each element should be enough).
My gut feeling is that this is not simple enough. The heuristic is that a new tech has to offer roughly a magnitude in improvement for it to take off. I don't see this as being 10x easier than javascript. Maybe my eyes are clouded. Try asking a novice what he thinks.
Who is going to use this? People who develop complex apps are going to deal with programming anyway, so they won't use this over XForms or HTML forms or Java applets. People who are throwing together web sites will use HTML forms and canned scripts in Frontpage or DreamWeaver.
I'm not sure this a middle ground between HTML forms and DHTML that's worth taking.
I think the book Creating Applications with Mozilla might be worth checking out. The concept of using XML to define and structure a GUI is well worth it.
For a lighter-weight approach to the same problem check out the MSDN article on MotLib.Net (with plenty of C# examples) It's the start of a bare-bones XML based Winforms framework, but it is simple enough to understand in a single sitting. You can extend it fairly easily.
Everyone talks about MVC/Observers-Adapters, but I find that the Command pattern is underrated. Implement all actions using objects: this makes state management a lot easier, and makes scripting and consistent security a lot easier to handle. Having commands decoupled from the UI also lends itself to unit testing, something which becomes difficult to manage once the user interface starts waiting for input.
Computer SCIENCE is very much part of mathematics. Denying it just proves that you slept through class, or avoided taking the hard classes because they had math in them.
Computer SCIENCE comes up with tools like VDM and Z (formal methods) that can be applied by ENGINEERS to verify that the software that was built.
Application Software construction is very much like movie-making already. You usually have a director (architect/designer), lighting and camera-crews (database and graphics experts) and so on. However, they all use tools like cameras, lights, and cranes (compilers, database engines, Open-GL drivers). These tools are usually certified by ENGINEERS who have used the processes that SCIENCE gave them.
Beautiful stuff does come out of the IEEE. 802.11b for example. Wi-Fi or Airport the marketing departments are calling it. Quite popular these days, apparently.
Ah, but I think that part of the point was that different people seek to maximize utility within different markets. (or to use an ESR term: Noospheres)
i.e. Linux hackers seek to maximize their reputations within the Linux-credibility market, while Hollywood players seek to maximize their status in the Hype market...
Utility theory is a useful theory for examining behavior in a market. It isn't a complete socio-economic model for reality.
I've got one Schildt book that is damn useful. It's his book on the STL. It's brand new and it covers the ISO standard STL. It's the only readable introduction to the STL that does not start with an assumption that you care deeply about the implementation differences between different sorts of iterators. (yes I care, but not in the middle of a tutorial)
"Thinking in C++" (Bruce Eckel) just confused the heck out of us -- we spent more time disentangeling the code samples than we spent talking about what was actually going on.
But yeah, the Schildt C++ bibles and whatnot are good doorstops.
The current UCC proposal makes shrinkwrap and clickwrap agreements binding. i think the Communications of the ACM had a big story about it a few months back.
Basically the current UCC proposal looks really bad for consumers, but very good for vendors. (big surprise there, I know).
The patent seems to focus on client-server-network-server-client situations (multiple clients, multiple interacting servers), which does not seem to cover games like Quake or Doom, since they are client-server-client (i.e. multiple clients connect to a single server).
Even Ultima Online does not have interacting servers - at least not in the sense the patent intends the servers to interact. Each UO server is a closed world.
Prey might come close to meeting the claims of the patent, since there someone attached to one server could shoot someone on another server.
IRC has already been mentioned as prior art for the patent (#channels == zone of interest).
But anyway, there's nothing in the patent a good engineer wouldn't develop in the course of developing a heavily distributed system (think Quake for 2000 players, for example).
Slashdot Mirror
i.e. a message can be From the CEO, while the Sender is the administrative assistant.
The upside on this approach is that it avoids mucking with Reply-To, which is something that can cause problems for some (mailing lists don't always like it)
I don't think this simplifies UI coding enough for people to consider switching. I may be confounded by the verbosity of the spec though.
For example: is it really necessary to specify the skin on every element? All those XLINKs should default to sensible values unless I want the controls all to be purple for some reason, in which case I can understand the need to be verbose.
CSS is a great tool for tweaking the look of something. Could you not leverage that? stateHover and the like are re-inventing stuff that CSS already does.
I like the way list and menu elements are defined, although it may be overkill for most uses (having just an ID for each element should be enough).
My gut feeling is that this is not simple enough. The heuristic is that a new tech has to offer roughly a magnitude in improvement for it to take off. I don't see this as being 10x easier than javascript. Maybe my eyes are clouded. Try asking a novice what he thinks.
Who is going to use this? People who develop complex apps are going to deal with programming anyway, so they won't use this over XForms or HTML forms or Java applets. People who are throwing together web sites will use HTML forms and canned scripts in Frontpage or DreamWeaver.
I'm not sure this a middle ground between HTML forms and DHTML that's worth taking.
For a lighter-weight approach to the same problem check out the MSDN article on MotLib.Net (with plenty of C# examples) It's the start of a bare-bones XML based Winforms framework, but it is simple enough to understand in a single sitting. You can extend it fairly easily.
Everyone talks about MVC/Observers-Adapters, but I find that the Command pattern is underrated. Implement all actions using objects: this makes state management a lot easier, and makes scripting and consistent security a lot easier to handle. Having commands decoupled from the UI also lends itself to unit testing, something which becomes difficult to manage once the user interface starts waiting for input.
(How this scores 3 is a mystery)
Computer SCIENCE is very much part of mathematics. Denying it just proves that you slept through class, or avoided taking the hard classes because they had math in them.
Computer SCIENCE comes up with tools like VDM and Z (formal methods) that can be applied by ENGINEERS to verify that the software that was built.
Application Software construction is very much like movie-making already. You usually have a director (architect/designer), lighting and camera-crews (database and graphics experts) and so on. However, they all use tools like cameras, lights, and cranes (compilers, database engines, Open-GL drivers). These tools are usually certified by ENGINEERS who have used the processes that SCIENCE gave them.
Beautiful stuff does come out of the IEEE. 802.11b for example. Wi-Fi or Airport the marketing departments are calling it. Quite popular these days, apparently.
>WTO talks and demos are underway in Japan this week.
The WTO talks are in Doha, Quatar. (That's in the Middle East - just south-east of Kuwait)
If this is indicative of the depth of research and thought that has gone into this piece... then it's not really worth the pixels it's printed on.
Which is a pretty non-obvious thing to do. (I've been using Photoshop for years and had no idea it could do this) And therefore it's patentable.
Ah, but I think that part of the point was that different people seek to maximize utility within different markets. (or to use an ESR term: Noospheres)
i.e. Linux hackers seek to maximize their reputations within the Linux-credibility market, while Hollywood players seek to maximize their status in the Hype market...
Utility theory is a useful theory for examining behavior in a market. It isn't a complete socio-economic model for reality.
>"More people have ascended bodily into heaven
/. I think.
>than have shipped great software on time."
The quote is from Jim McCarthy, in his most excellent book "Dynamics of Software Development".
(It's a Microsoft Press book, and McCarthy used to be in charge of the Visual C++ developer team)
There's a review of it here on
I've got one Schildt book that is damn useful. It's his book on the STL. It's brand new and it covers the ISO standard STL. It's the only readable introduction to the STL that does not start with an assumption that you care deeply about the implementation differences between different sorts of iterators. (yes I care, but not in the middle of a tutorial)
"Thinking in C++" (Bruce Eckel) just confused the heck out of us -- we spent more time disentangeling the code samples than we spent talking about what was actually going on.
But yeah, the Schildt C++ bibles and whatnot are good doorstops.
The current UCC proposal makes shrinkwrap and clickwrap agreements binding. i think the Communications of the ACM had a big story about it a few months back.
Basically the current UCC proposal looks really bad for consumers, but very good for vendors. (big surprise there, I know).
IANAL, but...
The patent seems to focus on client-server-network-server-client situations (multiple clients, multiple interacting servers), which does not seem to cover games like Quake or Doom, since they are client-server-client (i.e. multiple clients connect to a single server).
Even Ultima Online does not have interacting servers - at least not in the sense the patent intends the servers to interact. Each UO server is a closed world.
Prey might come close to meeting the claims of the patent, since there someone attached to one server could shoot someone on another server.
IRC has already been mentioned as prior art for the patent (#channels == zone of interest).
But anyway, there's nothing in the patent a good engineer wouldn't develop in the course of developing a heavily distributed system (think Quake for 2000 players, for example).