Thanks Eelco for the response! I appreciate the update. As I am trying to sell wicket for use on a lot of applications, I do see the knee-jerk you describe. I am not concerned about memory usage, but more about the ability to persist it (via session persistence) efficiently, because I work in health care, a lot of people here are all about 99..999 availability, and of course appserver clustering always comes up in this discussion. I am optimistic that having a reasonably sized page history, and using idetachable models should keep things to a reasonable size. Do you have any experience using session persistence with a medium size app (say 50-100 pages)? eg> what session size can we expect?
Thanks again James Eelco Hillenius wrote: > On 7/12/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > >> the real client side wicket , so storing the data in the browser didn't make >> it >> and i don't think it will make it very soon because no current committer >> really sees >> the big benefit of this approach. >> > > Yep. We played with it a while ago and we have a fair idea how to do > it but we felt it wasn't worth the energy to keep working on it. > > There are disadvantages to client side state saving: > * First of all you'd lose the secure-by-default model you have with > Wicket. For instance, imagine having a detail panel for a product. If > you pass around objects (or ids) on the server side, there is no way a > client could get access to the details he/ she is not supposed to see. > When passing state via the client, you would always have to check the > incoming state for misuse. This is actually a pretty strong feature > Wicket has over most other frameworks. The other side of this is that > if you want to have your whole app bookmarkable, you'll have to do > some extra work :) > * Secondly, synchronously serializing, encoding and sending the state > to the client eats processor time and bandwith. The size of the > serialized, encoded state will be larger than than on the server. Even > if we do something really smart, chances are we're sending *at least* > 20KB to the client on each request. Maybe even more. We think using > RAM is way more favorible. > * Last but not least, GETs have to be made POSTs or you'd have to run > the risk that state doesn't fit a request. > > Of course, there are advantages to client state saving as well: > * No worries about RAM, at least not because of Wicket[1]. > * Pages are recoverable by default. Even when a session times out, you > could let the client pick up where he/ she left. > * No need for session affinity[2] > > Conclussion: we don't support client side state saving currently, and > we don't feel it's a priority at this time. However, if someone does > feel it is important, we'd be more than happy to look at patches. I > think the easiest way to achieve this is to implement it as a > IResponseFilter and a custom session store. > > Eelco > > > [1] worrying about using RAM is the typical knee-jerk reaction of > people. Before worrying, calculate how many concurrent sessions you'll > have to support, and how much RAM you'd need for that. > [2] this increases your options when it comes to the way you cluster, > though not using session affinity can have disadvantages as well (for > instance when using ORM caches). > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
