| 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 |