| 2012-02-29 10:11:17 utc | tosch_le | Hello! |
| 2012-02-29 10:11:39 utc | jmettraux | tosch_le: hello! Long time no see! |
| 2012-02-29 10:14:00 utc | tosch_le | a too long time, i'd say, but i was rather busy at work |
| 2012-02-29 10:14:20 utc | jmettraux | successfully I hope |
| 2012-02-29 10:15:34 utc | tosch_le | i hope, too. we are not finished yet, but close to. now i had some time to look into the modified worker which uses inotify to watch the fs storage. |
| 2012-02-29 10:16:06 utc | tosch_le | it seems to work, but running ruote's test suite is not possible as wait_for does not work for my solution |
| 2012-02-29 10:16:59 utc | jmettraux | sounds neat anyway |
| 2012-02-29 10:18:43 utc | tosch_le | it should decrease io load by some amount, and that's what we need here. |
| 2012-02-29 10:19:39 utc | jmettraux | you only use it for "msgs"? |
| 2012-02-29 10:19:45 utc | tosch_le | let's see, i'll put my sources to github during the next day, maybe you'll have the time to have a look. |
| 2012-02-29 10:20:00 utc | tosch_le | no, it should be used for 'schedules' as well. |
| 2012-02-29 10:20:51 utc | jmettraux | is it OSX and Linux? |
| 2012-02-29 10:20:52 utc | tosch_le | (have to find a solution for situations when the 'schedules' directory doesn't exist on initialization) |
| 2012-02-29 10:21:16 utc | tosch_le | it uses https://github.com/mockko/em-dir-watcher/ under the hood |
| 2012-02-29 10:21:20 utc | jmettraux | (I'd suggest creating the directory) |
| 2012-02-29 10:22:01 utc | tosch_le | sounds like a good solution :-) |
| 2012-02-29 10:22:18 utc | tosch_le | em-dir-watcher has support for mac os x, windows and linux |
| 2012-02-29 10:22:36 utc | jmettraux | excellent |
| 2012-02-29 10:28:56 utc | jmettraux | I have to release 2.3.0 soon, but I'm stuck working on ruote-swf, then I have to finish ruote-amqp's rework and I've got a ruote-fluo SVG branch that's starting to look good |
| 2012-02-29 10:29:07 utc | jmettraux | but that SVG thing can wait and get released later |
| 2012-02-29 20:10:13 utc | jmettraux | hartog: hello |
| 2012-02-29 20:14:18 utc | hartog | jmettraux: hi! |
| 2012-02-29 20:14:53 utc | hartog | has the storage interface been improved in 2.3.0? |
| 2012-02-29 20:15:23 utc | jmettraux | somehow modified yes, I'm not sure if it's an improvement |
| 2012-02-29 20:15:45 utc | jmettraux | but it shouldn't be much modification, and the tests should help |
| 2012-02-29 20:15:59 utc | hartog | i'm very much confused with return values of put |
| 2012-02-29 20:16:28 utc | hartog | according to http://ruote.rubyforge.org/implementing_a_storage.html#interface |
| 2012-02-29 20:16:37 utc | hartog | (and I even wrote that) |
| 2012-02-29 20:17:20 utc | jmettraux | yes, it's a bit "reversed" |
| 2012-02-29 20:17:42 utc | jmettraux | but the idea is that when something trueish is returned it means it didn't work as expected |
| 2012-02-29 20:18:11 utc | jmettraux | true = the put failed, the document is gone |
| 2012-02-29 20:18:20 utc | hartog | so; document when it worked, true when it didn't |
| 2012-02-29 20:18:26 utc | jmettraux | doc = the put failed, the document has changed meanwhile |
| 2012-02-29 20:18:34 utc | jmettraux | nil = your put was a success |
| 2012-02-29 20:18:40 utc | hartog | aha |
| 2012-02-29 20:18:46 utc | hartog | ok thx! |
| 2012-02-29 20:19:54 utc | hartog | so; what are your plans for the rework of amqp? |
| 2012-02-29 20:21:27 utc | jmettraux | it's somehow outlined in https://groups.google.com/d/topic/openwferu-users/1KI6P6hBoR4/discussion (first email) |
| 2012-02-29 20:22:38 utc | hartog | quick storage question inbetween: "doc = the put failed, the document has changed meanwhile", is the 'doc' the doc you provided, or the new, 'current' doc? |
| 2012-02-29 20:23:31 utc | jmettraux | the doc returned is the up-to-date version of the document; so that you can redo your work, starting from the up-to-date version |
| 2012-02-29 20:27:39 utc | hartog | ow, I missed the part about spec2/ on my first ''read'' through |
| 2012-02-29 20:29:10 utc | hartog | would it not make more sense to do a pub/sub topical exchange rather then a direct one? |
| 2012-02-29 20:29:54 utc | jmettraux | for a simple test, I don't think so |
| 2012-02-29 20:30:12 utc | jmettraux | I think that the whole exchange setup should be left out of ruote-amqp |
| 2012-02-29 20:30:45 utc | jmettraux | the direct exchange I use in this initial spec is the simple thing I could possibly use for testing/specing |
| 2012-02-29 20:31:19 utc | jmettraux | I don't want to force topology choices on people |
| 2012-02-29 20:32:50 utc | hartog | ACTION cooks up a gist |
| 2012-02-29 20:41:53 utc | jmettraux | s/simple thing/simplest thing/ |
| 2012-02-29 20:44:38 utc | hartog | you speak Perl, eh... |
| 2012-02-29 20:45:09 utc | hartog | https://gist.github.com/1944228 |
| 2012-02-29 20:45:33 utc | hartog | i believe that should be the way if you want to leave topic setup out of the frame |
| 2012-02-29 20:45:57 utc | hartog | but then without typoos |
| 2012-02-29 20:46:27 utc | jmettraux | ok, makes sense |
| 2012-02-29 20:48:29 utc | jmettraux | added link to your gist to my todo list |
| 2012-02-29 20:49:47 utc | hartog | not sure yet what a receiver should look like |
| 2012-02-29 20:50:08 utc | hartog | but neither are you, judging by the contents of that spec :-> |
| 2012-02-29 20:50:18 utc | jmettraux | something that binds to a queue |
| 2012-02-29 20:50:29 utc | jmettraux | listens to a queue |
| 2012-02-29 20:52:08 utc | hartog | and then publishes back |
| 2012-02-29 20:52:47 utc | hartog | there is still some configuration-over-convention in there, like; where does on put return messages? |
| 2012-02-29 20:52:59 utc | jmettraux | I don't think so, the participant publishes |
| 2012-02-29 20:53:17 utc | jmettraux | I don't understand your question |
| 2012-02-29 20:53:53 utc | hartog | worker publishes on "third.star.to.the.right" something somewhere listens to that |
| 2012-02-29 20:53:58 utc | hartog | and it replies |
| 2012-02-29 20:54:08 utc | hartog | (or not) |
| 2012-02-29 20:54:11 utc | hartog | but where? |
| 2012-02-29 20:54:48 utc | jmettraux | not necessarily ruote-amqp's responsibility |
| 2012-02-29 20:55:21 utc | hartog | indeed |
| 2012-02-29 20:55:38 utc | hartog | that makes it sort of tricky and in desperate need of solid documentation ;-) |
| 2012-02-29 20:55:57 utc | jmettraux | in need of people educated about [ruby]amqp |
| 2012-02-29 20:56:17 utc | jmettraux | should we get in the way of ruby-amqp with too much "convention" ? |
| 2012-02-29 20:58:04 utc | jmettraux | the point about documentation is taken |
| 2012-02-29 21:00:20 utc | hartog | i updated the gist with a receiving participant |
| 2012-02-29 21:01:18 utc | hartog | still not sure about the reply address though |
| 2012-02-29 21:03:21 utc | jmettraux | a participant is instantatied for each dispatch |
| 2012-02-29 21:03:49 utc | jmettraux | ok, it works like a "listen" point |
| 2012-02-29 21:04:13 utc | jmettraux | a listener listens all the time |
| 2012-02-29 21:04:43 utc | jmettraux | the pattern is more like listener = Listener.new(dashboard) |
| 2012-02-29 21:05:49 utc | hartog | yes, but not all messages should keep the workflow waiting |
| 2012-02-29 21:06:01 utc | jmettraux | ? |
| 2012-02-29 21:07:03 utc | hartog | i just want to message something that a new workflow has been kicked off, but the workflow should not be blocked until this something has finaly replied |
| 2012-02-29 21:07:47 utc | hartog | let me cook-up some more pdefs :-) |
| 2012-02-29 21:07:54 utc | jmettraux | ok, that's the role of the |
| 2012-02-29 21:08:04 utc | jmettraux | "forget" participant configuration |
| 2012-02-29 21:09:06 utc | jmettraux | if 'forget' is on, the participant will immediately reply to the engine (please resume flow) |
| 2012-02-29 21:10:39 utc | jmettraux | there is a usecase that you're hinting at that's interesting me: when you fire a participant that simply listens on a queue (with no prior publishing), I think it might be useful |
| 2012-02-29 21:11:34 utc | hartog | me 2 |
| 2012-02-29 21:17:59 utc | jmettraux | thanks for the great feedback! |
| 2012-02-29 21:18:30 utc | hartog | added some pdefs to the gist |
| 2012-02-29 21:18:39 utc | hartog | might prove usefull |
| 2012-02-29 21:20:25 utc | jmettraux | yes |
| 2012-02-29 21:23:13 utc | hartog | the catch here is that the Stephen King example should kick in a new process also listening up-on reception |
| 2012-02-29 21:23:55 utc | hartog | and that you would expect that the x-factor example runs perhaps once and waits for this specific workitem to return |
| 2012-02-29 21:26:03 utc | jmettraux | I think that the stephen king example is best served by a "launch listener" |
| 2012-02-29 21:26:39 utc | jmettraux | something that independently listens to a queue and starts flows |
| 2012-02-29 21:26:51 utc | hartog | would seem the right term |
| 2012-02-29 21:28:00 utc | hartog | but would this be a part of the process definition? |
| 2012-02-29 21:28:28 utc | jmettraux | not at all |
| 2012-02-29 21:28:36 utc | hartog | or would the process definition be a part of the instantiation of a Ruote::Amqp::LaunchListener |
| 2012-02-29 21:29:09 utc | jmettraux | or else you could use of those listen-only participants and launch a subworkflow |
| 2012-02-29 21:29:35 utc | jmettraux | s/use of/use one of/ |
| 2012-02-29 21:31:32 utc | jmettraux | repeat do; wait_for_message; launch_subflow; end |
| 2012-02-29 21:33:20 utc | hartog | updated once more |
| 2012-02-29 21:33:28 utc | hartog | the gist, that is |
| 2012-02-29 21:35:05 utc | jmettraux | in stephen_king.rb the listener needs to know about the dashboard/engine |
| 2012-02-29 21:35:38 utc | hartog | or not |
| 2012-02-29 21:35:47 utc | hartog | dashboard.attach(listener) seems very elegant |
| 2012-02-29 21:37:21 utc | hartog | (my github speeds are blazing! Receiving objects: 13% (3153/24235), 860.00 KiB 1 KiB/s ) |
| 2012-02-29 21:37:36 utc | hartog | (trying to get a fresh clone off ruote to test my riak storage driver thingy |
| 2012-02-29 21:37:46 utc | hartog | its not really going anywhere) |
| 2012-02-29 21:39:42 utc | jmettraux | I don't like having to feed a receiver with a process definition, I much prefer if people set up their own worker and launch workflows the standard way |
| 2012-02-29 21:40:30 utc | jmettraux | I will think about it |
| 2012-02-29 21:40:49 utc | jmettraux | for now my goal is to rewrite the features found in the current ruote-amqp |
| 2012-02-29 21:41:07 utc | jmettraux | so that I'm able to maintain it and offer support for it |
| 2012-02-29 21:42:16 utc | hartog | sounds like a decent goal, godspeed then! |
| 2012-02-29 21:42:25 utc | jmettraux | thanks |
| 2012-02-29 21:42:29 utc | hartog | I hope i didnt confuse you to much ;-) |
| 2012-02-29 21:45:28 utc | jmettraux | no, not all, you gave me a clearer idea of "future expectations" for ruote-amqp |
| 2012-02-29 21:46:01 utc | jmettraux | also got thinking about composition over convention over configuration |
| 2012-02-29 21:48:09 utc | hartog | there might be even more expectations out there... Perhaps you should ask people on the mailing list to write a gist as to how they envision ruote-amqp working, this might create chaos, but it could also bring forth some usefull DSL information |
| 2012-02-29 21:51:03 utc | jmettraux | yes, I should probably try |
| 2012-02-29 22:07:29 utc | hartog | ok, the test for ruote-riak are running: 27 tests, 28 assertions, 12 failures, 4 errors, 0 skips |
| 2012-02-29 22:07:41 utc | hartog | but more of that later |
| 2012-02-29 22:07:52 utc | hartog | because now, it is bed time zzz |