i agree with a lot of what eelco says here. that said, i'm definitely more of the mind to prefer stateful OO techniques over stateless. also, i think the idea that amazon is actually a stateless web site is probably somewhat false already and getting more false as the company grows and scales the complexity of their site. even at a company like amazon (actually, /particularly/ at a company like amazon given their scale), it would be smartest to stress test a simulation/mockup to estimate your actual dollar cost per request (or session) over a long period of time (some number of years). there are a lot of variables involved and any solid estimate is probably better than guessing or going on yesterday's institutional "wisdom". just as an example, ten years ago, nobody really believed java would ever be fast enough for all the things we're using it for today. 15 years ago, a megabyte of memory was nearly unthinkable. it might or might not be a good idea to scale a stateful site today, but i'd be willing to bet money that it will be a very good idea before long. the costs of statefulness are ramping down fast (in a few short years we will have very cheap 64 bit systems with dozens or hundreds of GB of ram, terabytes of high speed solid state disk, scores of processors, etc... an order of magnitude improvement in every dimension should be expected) and on the flip side, the savings on the complexity/development side are large and growing. programming is all about bookkeeping and stateful encapsulation is a winner in the end. my point is not that you should develop amazon in wicket right now, but that at some point (and i think soon) it definitely /will/ make sense to do so. not understanding where we are concerning these cost curves could be an incredibly expensive mistake for a company with hundreds or thousands of employees and it's not something i'd determine with a bunch of hand waving or expert opinions. you've got to do the test to find out.
Doug Donohoe wrote: > > Eelco, > > Thanks for the thorough and thoughtful reply. Perhaps there are things > that can be done in the framework with cookies and such. > > I am going to be looking to additions to wicket. I need to get the source > built and working in my local environment. > > -Doug > > > > Eelco Hillenius wrote: >> >> >>> Another approach is to provide a more graceful session-expiration >>> strategy. >>> In many cases, you could redisplay the original page (perhaps there are >>> cases where the no-arg constructor would work). >> >> A much better way of solving your problems is to work with plenty of >> bookmarkable pages AND use cookies to recognize that you could pick up >> a session again, and you could even for instance save the last page or >> pages a user visited in the last visited etc (I'm sure Amazon does >> something like that). You'll just have to plan carefully for it, and >> depend more on your own brainpower than to expect everything to come >> from the framework. >> >>> Finally, there are likely cases where parts of a page could be stateful >>> and >>> others stateless. In my case, even though I display a login form via >>> Ajax, >>> it still should be possible to submit it in a stateless format. >>> >>> Let me end by saying that I am a big believer in the framework. >>> However, I >>> feel the session expiration issue is a stumbling block. I welcome >>> others >>> perspectives on this. >> >> The problem that Wicket tries to solve is quite hard*, and >> consequently the framework has gotten quite complex. The more we >> facilitate corner cases and try to be a framework that fits all >> imaginable problems, the harder the framework will be too maintain, >> and - due to having more options to cover - the harder it may be to >> use. >> >> We've taken some serious looks at how to come up with a hybrid model >> and push Wicket into supporting even more stateless use cases, but so >> far these efforts stranded because the solutions we came up with were >> very hackish and would probably open up a big fat can of worms we >> wouldn't be able to support properly. Maybe we can improve things here >> and there (we're all for that!), but it is really important that >> people come up with intelligent solutions (patches would be great) >> rather than just stating shortcomings. >> >> Cheers, >> >> Eelco >> >> > > -- View this message in context: http://www.nabble.com/Wiket-2.0-time-frame-tp16992791p17036614.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
