OK... Here is one question. What is a typical legitimate use of
this feature? Right now, I use my own SessionManager to store user
information (basically, an account bean representing the current
user). This is not very different from a session variable as I
cannot control the scope of the object (as outlined in your review
of pros/cons of session variables). Would it be legitimate here to
store this bean using the session storage?
Actually, the main use of this feature is storage of data on the
server-side for performance, size, or security reasons. The semantics
of the data in the state transitions are exactly the same as what you
know with globalvars and datalinks, they just are stored in the
session instead of in the query string or hidden form parameters.
Note that this is totally different from regular session access,
since each state transition gets a unique ID and the entire state is
stored in the session. This makes the back button and bookmarking
still work, as long as the session isn't purged.
Why are so many projects bragging about things that RIFE does
easier and more consistently? I don't know, but it's frustrating
indeed. A notable entry there is Jetty 6's 'continuations' feature
that aren't even continuations at all, but parked requests.
Blogosphere destroys individuality and any chance of individual
thought. Nowadays, if someone is a good writer/speaker, he/she can
pass anything as the absolute thruth by introducing it in the
blogosphere.
Hence why we need more people blogging about RIFE! (hint, hint) ;-)
--
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34
http://www.uwyn.com 7170 Manage, Belgium
gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
