Re: A plea - WAS Re: [OS-webwork] Reflection
On Tue, 2003-01-14 at 21:17, Robert Nicholson wrote: Why does it have to be a MDB? Can't you just make a listener? What will an MDB buy you? In a word: transactions (oh also instance caching for tuning but that would be more than 1 word :) ) We use a lot of MDBs in our app for these reasons. -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- This SF.NET email is sponsored by: Take your first step towards giving your online business a competitive advantage. Test-drive a Thawte SSL certificate - our easy online guide will show you how. Click here to get started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: A plea - WAS Re: [OS-webwork] Reflection
On Mon, Jan 13, 2003 at 08:30:17AM +0100, Rickard Öberg wrote: 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' 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*. I think we should keep swing clients out of the discussion at the moment. Although I do not have very much experience with swing clients, the design patterns differ from the request-response pattern of web or rpc clients. So I see no problem in pushing the development slightly away from the web to a more generic request-response pattern. -billy. -- Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0 eLösungen 89077 Ulm Fax: +49-731-399 499-9 msg01183/pgp0.pgp Description: PGP signature
Re: A plea - WAS Re: [OS-webwork] Reflection
After reading this for a while I cannot recall who asked for swing clients in the first place. I don't think they were ever a requirement. In terms of non web stuff I would like to see something that could talk to JMS in an asynchronous manner but I'm not going to lose sleep if it's outside the scope. We have developed a somewhat webwork like Message EJB implementation which will do fine for the forseeable future. On Mon, 2003-01-13 at 20:20, Philipp Meier wrote: I think we should keep swing clients out of the discussion at the moment. Although I do not have very much experience with swing clients, the design patterns differ from the request-response pattern of web or rpc clients. So I see no problem in pushing the development slightly away from the web to a more generic request-response pattern. -billy. -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: A plea - WAS Re: [OS-webwork] Reflection
Funny, we were just talking about this here today. We've got a simple command pattern implementation for running batch jobs now, and I was talking about how, if we moved to Webwork, we could make a MessageDrivenDispatcher (an MDB) that would run jobs asynchronously... -Original Message- From: Peter Kelley [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 5:28 PM To: [EMAIL PROTECTED] Subject: Re: A plea - WAS Re: [OS-webwork] Reflection After reading this for a while I cannot recall who asked for swing clients in the first place. I don't think they were ever a requirement. In terms of non web stuff I would like to see something that could talk to JMS in an asynchronous manner but I'm not going to lose sleep if it's outside the scope. We have developed a somewhat webwork like Message EJB implementation which will do fine for the forseeable future. On Mon, 2003-01-13 at 20:20, Philipp Meier wrote: I think we should keep swing clients out of the discussion at the moment. Although I do not have very much experience with swing clients, the design patterns differ from the request-response pattern of web or rpc clients. So I see no problem in pushing the development slightly away from the web to a more generic request-response pattern. -billy. -- Peter Kelley [EMAIL PROTECTED] Moveit Pty Ltd --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi- bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
