ruote tmp/log_2012-02-29.html

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 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
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 (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
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 "" 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 =
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