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 |