It's way less complicated and can be solved on a case-by-case basis (AKA do I really need this stuff?). For one, you could almost trivially implement it in ERD2W.
Cheers, Anjo Am 08.03.2010 um 21:24 schrieb Mike Schrag: > 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]
