ruote tmp/log_2012-05-11.html

2012-05-11 07:19:15 utc wtian What's the difference between a storage_participant and a local_participant?
2012-05-11 07:41:28 utc jmettraux wtian: hello and welcome to #ruote
2012-05-11 07:42:18 utc jmettraux Ruote::LocalParticipant is a mixin, it features methods shared by participants, a better name would probably be just Ruote::ParticipantMixin
2012-05-11 07:42:34 utc jmettraux Ruote::StorageParticipant is a full participant implementation
2012-05-11 07:43:07 utc jmettraux when it receives a workitem, it stores it in the storage, it then makes it available to clients
2012-05-11 07:43:12 utc jmettraux that's it.
2012-05-11 07:48:29 utc wtian Hi John, thanks for the prompt reply.
2012-05-11 07:50:27 utc wtian If I implement my own Ruote participant by including the LocalStorage mixin, will this implmentation be stored in the storage, just like the StorageParticipant?
2012-05-11 07:52:09 utc jmettraux no
2012-05-11 07:52:40 utc jmettraux of course not
2012-05-11 07:53:50 utc wtian Then how will my own participant receive workitems?
2012-05-11 07:54:01 utc jmettraux and there is no LocalStorage mixin
2012-05-11 07:54:52 utc wtian you mean there is no StorageParticipant Mixin?
2012-05-11 07:54:53 utc jmettraux your participant will receive workitem because a) it's register in the engine b) it has a valid on_workitem method
2012-05-11 07:55:17 utc jmettraux no there is no Ruote::StorageParticipant mixin, there is a Ruote::StorageParticipant class
2012-05-11 07:56:13 utc wtian but are they persisted?
2012-05-11 07:56:51 utc jmettraux look at the quickstart: http://ruote.rubyforge.org/quickstart.html there is no Ruote::StorageParticipant involved
2012-05-11 07:57:18 utc jmettraux does a participant that adds 1 and 2 need to be persisted? no.
2012-05-11 07:58:26 utc jmettraux because it replies immediately to the engine
2012-05-11 08:01:07 utc wtian ok. Now I am a bit confused. The workflow process will be persisted by the engine storage. Does StorageParticipant have its own persistence?
2012-05-11 08:01:42 utc jmettraux ok
2012-05-11 08:01:47 utc jmettraux about your confusion
2012-05-11 08:02:01 utc jmettraux you asked: "16:44 wtian: If I implement my own Ruote participant by including the LocalStorage mixin, will this implmentation be stored in the storage, just like the StorageParticipant?"
2012-05-11 08:03:06 utc jmettraux which can be rephrased as "If I implement my own bike by including the Cabbage mixin, will this implementation be stored in the Shed, just like the ShedBike?"
2012-05-11 08:03:16 utc jmettraux it's not logic
2012-05-11 08:03:42 utc jmettraux ok, end of "confusion" parentheses, let's move on
2012-05-11 08:03:55 utc wtian i see :-)
2012-05-11 08:04:08 utc jmettraux the StorageParticipant uses the same storage as the engine
2012-05-11 08:04:15 utc jmettraux it's a participant implementation
2012-05-11 08:04:40 utc jmettraux a basic participant receives a workitem and at some point replies to the engine with the updated (or not) workitem
2012-05-11 08:05:00 utc jmettraux the storage participant is an implementation/specialization that stores the workitem for later manipulation
2012-05-11 08:05:27 utc jmettraux at some point, some "client" comes, lists the workitems in the storage participant, modifies them, saves them or proceeds them
2012-05-11 08:05:46 utc jmettraux by proceeding them, the workitem get replied back to the engine and the flow resumes
2012-05-11 08:06:24 utc jmettraux are you a friend of Klaus?
2012-05-11 08:07:04 utc wtian So if a participant wants to be a part of a process that can endure a engine crash, it has to be a StorageParticipant?
2012-05-11 08:07:18 utc wtian No. I am not a friend of Klaus.
2012-05-11 08:07:49 utc jmettraux enduring crashes: no
2012-05-11 08:08:34 utc wtian I am currently located in China (Beijing), working on a Rails project.
2012-05-11 08:08:44 utc jmettraux ah ok
2012-05-11 08:08:51 utc jmettraux nice
2012-05-11 08:09:02 utc wtian I intend to use Ruote for the workflow. Still struggle with some of the concepts.
2012-05-11 08:09:22 utc jmettraux if you use the in-memory HashStorage storage, you'll never endure engine crashes
2012-05-11 08:09:54 utc jmettraux other storage are more "endurant"
2012-05-11 08:10:05 utc jmettraux other storages are more "endurant"
2012-05-11 08:10:46 utc jmettraux you can have engine crashes that lose workitems when dispatching to a StorageParticipant
2012-05-11 08:11:14 utc wtian But if I use, say, Redis for engine, with non-storage participant, participant won't be able to pick up where it left if the engine crashes, right?
2012-05-11 08:13:30 utc jmettraux this might interest you: https://groups.google.com/d/topic/openwferu-users/dPzoWeKZStw/discussion
2012-05-11 08:14:14 utc jmettraux you are right, you may have to "re_apply" where the workflow stalled
2012-05-11 08:21:17 utc wtian Thanks for the link. It clarified things a lot. As long as the process is persisted, and the engine is restarted after the crash, after re-apply, the participant (storage or non-storage participants) will get their workitems and resume the workflow, am I right?
2012-05-11 08:21:56 utc jmettraux yes
2012-05-11 08:23:43 utc wtian Thanks a lot. I may bug you from time to time in the coming months :-)
2012-05-11 08:23:56 utc wtian And thanks for the great work with Ruote.
2012-05-11 08:24:01 utc jmettraux please do :-) You're also welcome to use the mailing list
2012-05-11 08:24:09 utc wtian Will do.
2012-05-11 08:24:18 utc jmettraux thanks, have fun, looking forward to learn by working with you