you say that like it's trivial :) if that was easy, we wouldn't need a sweet stateful web framework ....
ms On Mar 8, 2010, at 3:09 PM, Anjo Krank wrote: > Bah. You don't really need to store the pages. You only need to store how > they can be reconstructed... > > Cheers, Anjo > > > > Am 08.03.2010 um 18:07 schrieb Mike Schrag: > >> Even within Apple, I would suspect that worked under VERY specific >> restrictions about what can be in your session at any point in time ... As >> soon as you start persisting the backtrack cache, it's going to get crazy >> complicated. >> >> On Mar 8, 2010, at 11:40 AM, Pascal Robert wrote: >> >>> So nobody outside Apple have been able to do this? :-( >>> >>>> when you're done implementing persistent session, let me know ... >>>> >>>> ms >>>> >>>> On Mar 8, 2010, at 11:13 AM, Johan Henselmans wrote: >>>> >>>>> I store a persistent PDsession EO (not related to WOSession): if a user >>>>> is timed out in a WOSessions, the next time the user logs in, the >>>>> information from the PDsession is restored unless they explicitely close >>>>> it. >>>>> >>>>> The problem that occurs is that sometimes a user logs itself in twice, so >>>>> the information in the PDsession is updated from two browsers. >>>>> >>>>> So I have to prevent a user to log in twice. >>>>> >>>>> An option I thought of was: >>>>> -store a WOSessionID in thePDsession >>>>> -when the user logs in, check if that session is still available in the >>>>> applications WOSessionStore. >>>>> -if so, refuse login >>>>> >>>>> Problem is that (as far as I know) applications do not share the >>>>> sessionID's so if there would be another WOApplicatiion that has the same >>>>> requirement, the user would still be able to login. >>>>> >>>>> So I thought of changing the WOSessionStore to something persistent, >>>>> instead of residing it in memory, and let the applications that have to >>>>> make use of such a requirement (user can only login on specific >>>>> application) to store their sessions in a persistent place. >>>>> >>>>> In noticed that way is also mentioned in: >>>>> >>>>> http://developer.apple.com/legacy/mac/library/documentation/MacOSXServer/Reference/WO54_Reference/com/webobjects/appserver/WOSessionStore.html >>>>> >>>>> " >>>>> There is one subclass of WOSessionStore implemented for the developer's >>>>> convenience. A server WOSessionStore (the default) stores session state >>>>> in the server, in application memory. The serverSessionStore method >>>>> returns this WOSessionStore. >>>>> >>>>> You can create a custom session store by making a subclass of >>>>> WOSessionStore. The subclass should properly implement the >>>>> saveSessionForContext andrestoreSessionWithID methods and should have a >>>>> public method that the application object can use to obtain an instance. >>>>> Some interesting session stores could be: >>>>> >>>>> • A database session store that stores session data in a database as >>>>> blobs, with the session ID as the primary key. This kind of >>>>> WOSessionStore can be shared by many instances of the same WebObjects >>>>> application, thus distributing the load (requests) among the instances. >>>>> • An adaptive session store that stores session state either in cookies >>>>> or on the server, depending on what the client supports. >>>>> If you create your own WOSessionStore class that generates persistent >>>>> objects, you should implement an algorithm that cleans up session state >>>>> after the session is inactive for a long time. The server WOSessionStore >>>>> provided by WebObjects performs this clean-up properly, but the API is >>>>> not yet public. >>>>> " >>>>> >>>>> I also noticed that in the Developer Examples There is the >>>>> WOSessionStoreExample Framework, that seems to implement something like >>>>> this. >>>>> >>>>> Does anybody have any experience with this technique, does it solve the >>>>> problem I am trying to tackle or is there another approach more >>>>> appropriate? >>>>> >>>>> >>>>> >>>>> Johan Henselmans >>>>> [email protected] >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list ([email protected]) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com >>>>> >>>>> This email sent to [email protected] >>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca >>>> >>>> This email sent to [email protected] >>> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/anjo%40krank.net >> >> This email sent to [email protected] > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
