+1+1+1 Michael Blake Day Artistry Studios - e-commerce design, implementation and hosting email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> mobile: 770.480.1547
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard Oberg Sent: Monday, January 13, 2003 2:30 AM To: [EMAIL PROTECTED] Subject: Re: A plea - WAS Re: [OS-webwork] Reflection Mike Cannon-Brookes wrote: > Some points that people seem to be forgetting: > - Xwork is in the SANDBOX and is eXperimental (if you like the X for that) > - Nothing in Xwork can't be changed, these are ideas, prototypes > - Xwork will be better for 'web work' than WebWork is! > - Xwork will be better for 'non web work' than WebWork is, _WITHOUT_ > impacting people who don't care for 'non web work' But the experimental sandbox is not emerging out of thin air. It is based on ideas, which are molded through various requirements. If there are two different sets of requirements, they lead to different ideas which lead to different code. If we can't agree on the requirements (a.k.a. goals), then that is much more important to discover than "writing cool code" and THEN discovering that we're not after the same thing. That WebWork turned out to be a generic command pattern was more of an accident then by design. Because of this genericity WebWork is not optimally designed for doing web work. Some of the "plumbing" needs to be done by actions themselves, instead of having it be done by the framework. I want to make WebWork/XWork *better* suited for the web, because that is what *I* *need*. I want to get more for less. I don't give a damn about making it work well in Swing. If it does, then whaddyaknow, cool. If it doesn't, shit happens. If there's ever a point where I need to decide between "keeping genericity, or making it work better for the web", the latter is a given. My recent emails have explained some of what I want to do in this area (introducing packages and components for example). Some of those are VERY web-centric, and that *IS THE POINT*. MAYBE it will never come to the point where there's such a decision, but there is a clear difference in what happens at that point in these two projects. In WebWork it is clear that if a decision benefits the web, then the web option it is. In XWork it is equally clear that if a decision may benefit the web but not Swing/EmailDispatcher/XDispatcher, then the generic option it is. This is how we have talked about the differences between WebWork and XWork, and this is the consequence of such different goals. I personally prefer the WebWork option, always. If you don't agree with my conclusions, then we have a different view of what the purpose of XWork is. I'm just going by what we have said are the intentions of this project. /Rickard ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
