| 2010-07-25 01:18:47 utc | dhf | lbt: you there? |
| 2010-07-25 01:27:27 utc | dhf | jmettraux: Good Morning. Is there any problem with reregistering participants? Trying to decide if I want to keep track of what is registered or just register new when needed. |
| 2010-07-25 01:27:53 utc | jmettraux | dhf: good afternoon, it should be OK |
| 2010-07-25 01:28:09 utc | jmettraux | if there is anything wrong please tell me |
| 2010-07-25 01:30:17 utc | dhf | I am doing the directory register and it works fine, but wanted to provide a way to reregister. I do maintain order. I am using beanstalkd as a queuing system for administration of the system. Wanted to provide a re-register participants as an option so new or modified ones could be updated. |
| 2010-07-25 01:31:33 utc | jmettraux | with the new engine.participant_list and engine.participant_list= you can do participant list administration in one go |
| 2010-07-25 01:39:37 utc | dhf | is the ParticipantEntry the class name of the participant and the class of the participant? |
| 2010-07-25 01:43:39 utc | jmettraux | http://github.com/jmettraux/ruote/blob/ruote2.1/lib/ruote/part/participant_list.rb#L308-339 it contains the regex, the classname and the options |
| 2010-07-25 01:55:36 utc | dhf | so when you call engine.participant_list = [/image.+/, [ImageParticipant, {:file => '/tmp/file', :patient => |
| 2010-07-25 01:55:54 utc | dhf | 'Don French') it will create the particioant registery |
| 2010-07-25 01:57:01 utc | jmettraux | ouch |
| 2010-07-25 01:57:30 utc | jmettraux | the participant list (registry) will already be created |
| 2010-07-25 01:57:40 utc | jmettraux | it will attempt to fit this data into it for you |
| 2010-07-25 01:57:56 utc | jmettraux | maybe this ParticipantEntry helper class is too confusing, I could remove it |
| 2010-07-25 01:58:38 utc | dhf | how would you use it? |
| 2010-07-25 01:59:24 utc | jmettraux | like at the beginning of http://groups.google.com/group/openwferu-users/msg/4e90738f92e797d5 |
| 2010-07-25 02:03:06 utc | dhf | so you still have to register the participant normally but can manage it via the list? |
| 2010-07-25 02:03:59 utc | dhf | with register_participants |
| 2010-07-25 02:04:20 utc | jmettraux | you can register it individually or you can register it via this list |
| 2010-07-25 02:04:58 utc | jmettraux | sorry for the distraction, but since you are into "participant administration", I wanted to show you this new feature |
| 2010-07-25 02:05:04 utc | jmettraux | comments are welcome |
| 2010-07-25 02:06:07 utc | dhf | very willing to look. |
| 2010-07-25 02:53:10 utc | dhf | jmettraux: Can you give me an example of registering using the list for a new participant? |
| 2010-07-25 02:57:42 utc | jmettraux | dhf: something like http://gist.github.com/489248 |
| 2010-07-25 02:57:52 utc | jmettraux | I have to say, I'm not convinced about it |
| 2010-07-25 03:01:58 utc | dhf | Got it. I missed that you had to stat with the existing list. to keep in order. If starting from new, jsut create a new array and start putting them in, then use participant_list= to set it. If I do that I do nto have to register the participant manually, right? |
| 2010-07-25 03:02:18 utc | jmettraux | right |
| 2010-07-25 03:02:41 utc | jmettraux | maybe I want to make it more flexible |
| 2010-07-25 03:02:42 utc | jmettraux | liek |
| 2010-07-25 03:02:44 utc | jmettraux | like |
| 2010-07-25 03:03:25 utc | jmettraux | list << [ '^toto$', Ruote::StorageParticipant, { 'variant' => 'doric' } ] |
| 2010-07-25 03:03:58 utc | jmettraux | the intricacies would be handled automagically |
| 2010-07-25 03:04:20 utc | jmettraux | not sure yet, hence my call for feedback |
| 2010-07-25 03:04:20 utc | dhf | that is good for initial building but would cause an issue for maint. |
| 2010-07-25 03:04:31 utc | dhf | I will experiment tonight |
| 2010-07-25 03:04:31 utc | jmettraux | how ? |
| 2010-07-25 03:04:34 utc | jmettraux | ok |
| 2010-07-25 03:23:51 utc | dhf | if you are using require_path/load_path, it goes as the second element of the array? |
| 2010-07-25 03:24:03 utc | jmettraux | yes, it's an option |
| 2010-07-25 03:27:48 utc | dhf | ok. I am trying it. changing my dir_registry to see if it is better. I will probably have to extend the class. I need some time information. if the participant on the disk is has not been changed since it was registered I see no need to unregister it as long as it is in the same priority. SO I have to keep that information. |
| 2010-07-25 03:28:54 utc | jmettraux | you could store it has an option |
| 2010-07-25 03:29:07 utc | jmettraux | '_last_modified' => t |
| 2010-07-25 03:29:25 utc | dhf | could, will try it |
| 2010-07-25 07:38:58 utc | lbt | I like engine.participant_list :) |
| 2010-07-25 07:39:31 utc | jmettraux | :) |
| 2010-07-25 07:39:56 utc | lbt | and.... good morning john |
| 2010-07-25 07:40:02 utc | jmettraux | good morning |
| 2010-07-25 08:00:54 utc | lbt | do you have something a little like a web management console onto ruote? something that can list running processes (or the wfids at least), and would also be able to list participants? |
| 2010-07-25 08:01:51 utc | jmettraux | already forgotten about ruote-kit ? |
| 2010-07-25 08:02:13 utc | jmettraux | http://github.com/tosch/ruote-kit but the edge is at http://github.com/jmettraux/ruote-kit |
| 2010-07-25 08:02:15 utc | lbt | just reading it ... |
| 2010-07-25 08:02:29 utc | jmettraux | I still have to implement the /participants resource |
| 2010-07-25 08:03:02 utc | jmettraux | I mentioned it in our exchanges on the mailing list |
| 2010-07-25 08:04:03 utc | lbt | *nod* I got the impression it was a code-level http api onto ruote ... which of course is an crucial part |
| 2010-07-25 08:04:36 utc | lbt | I'm looking for something shiney :) |
| 2010-07-25 08:04:42 utc | jmettraux | sorry |
| 2010-07-25 08:04:54 utc | lbt | not a problem.... worth asking |
| 2010-07-25 08:05:46 utc | jmettraux | my plan is to make it shiny within the end of the summer |