i stumbled on this the other day:
http://www.terracotta.org/web-sessions/
sounded on brief reading like a solution to this kind of thing.
simon
On 8 March 2010 16:15, Mike Schrag msch...@mdimension.com wrote:
when you're done implementing persistent session, let me know ...
ms
On Mar 8,
terracotta is a clustering solution, and WO is kind of funky to try and
implement with it ... WO Sessions are a lot more complex than sessions in
something like Tomcat. when you throw EOF into the equation (which you
invariably do -- your backtrack page has an editing context that has eos in
On Mar 9, 2010, at 4:59 AM, Johan Henselmans wrote:
Op 8 mrt 2010, om 17:58 heeft Ramsey Gurley het volgende geschreven:
Out of curiosity, what sort of data are you trying to restore with
PDsession?
It's basically information about the cashregister they are using. So
it contains
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
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
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
Out of curiosity, what sort of data are you trying to restore with
PDsession?
Ramsey
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
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
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
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
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
for non-D2W you have to implement that interface for every single component you
could ever use, though ... and deal with the fact that you could have pages
with uncommitted EO's, etc. for D2W you might be able to do a rough impl, but
you still can't general case it if people use custom
Am 08.03.2010 um 21:46 schrieb Mike Schrag:
for non-D2W you have to implement that interface for every single component
you could ever use, though ... and deal with the fact that you could have
pages with uncommitted EO's, etc. for D2W you might be able to do a rough
impl, but you still
13 matches
Mail list logo
