amazon is also a very simple site if i may say the webshop are a few pages at most ... Also they have a lot of cookies called "session" something... And i didnt see much change in the cookies when i added something to my card
but it could be encoded in one of them i guess. But removing some cookies didnt loose my order so i guess they do have something on the server.. By the way, amazon urls are really ugly.. i thought nice looking urls are soo important.... On Sat, May 3, 2008 at 8:47 PM, Jonathan Locke <[EMAIL PROTECTED]> wrote: > > > 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] > >
