My opinion is that commons-scxml could give two methods: get4Persistence() insertFromPersistence()
They could manage to return or accept a Vector of necessary objects like context, executor and scxml objects necessary to both stop and resume the SCXML Engine. If a developer wants to use Hibernate, Serialization or any other persistence method s/he can do it but is not forced to. How you store and retrieve the objects should be entire responsability of the System you design and not of the SCXML Engine. Just again my thoughts ;-) Thanks, -Nestor --- Rahul Akolkar <[EMAIL PROTECTED]> wrote: > On 9/7/06, Craig McClanahan <[EMAIL PROTECTED]> > wrote: > <snip/> > > > > In a recent TSSJS thread on Seam, I saw a wish > list item somewhat similar to > > this one, for a web specific use case ... the > ability to "checkpoint" all of > > the state machines currently active for a user so > that he or she can log out > > and go home, and then be able to restore them all > when the user logs on the > > next morning. > > > <snap/> > > Yes, save/restore scenarios are going to be > important to handle. > Moreover, I doubt there is going to be a > one-size-fits-all solution, > and folks are going to want to use muliple > strategies (continuations, > serialization etc.) to get at this. Sitthichai's > suggestion in > SCXML-20 [1] seems like a good way to proceed here. > Any other insights > welcome. > > -Rahul > > [1] https://issues.apache.org/jira/browse/SCXML-20 > > > > > > Craig > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
