ruote tmp/log_2012-07-27.html

2012-07-27 07:52:32 utc hartog jmettraux: I'm not yet giving up on the idea of a process observer, so I'm going to pick your brain a bit - is that OK?
2012-07-27 07:52:39 utc jmettraux no
2012-07-27 07:52:51 utc jmettraux please wait 3 minutes
2012-07-27 07:52:58 utc hartog ACTION sets timer ;)
2012-07-27 07:53:06 utc jmettraux :-)
2012-07-27 07:53:44 utc jmettraux hello by the way :-)
2012-07-27 07:55:22 utc hartog hello 2 u 2! new here?
2012-07-27 07:58:33 utc jmettraux ok, sometime I have trouble understanding your smsese
2012-07-27 07:59:15 utc hartog i was fooling around in a friday fashion; sorry :)
2012-07-27 07:59:18 utc jmettraux hartog: at first, how about stopping saying "process observer"? It seems you want to modify the msgs
2012-07-27 08:00:52 utc hartog no i dont want to modify msgs
2012-07-27 08:01:27 utc hartog it would be convenient to use the msgs as a storage mechanism for things as 'launched_at' or 'launched_by' or whatever
2012-07-27 08:01:47 utc hartog but one could easily store that somewhere else
2012-07-27 08:02:02 utc hartog and I really really want to observe a process
2012-07-27 08:02:32 utc hartog i want to see it get born and die of old age, so to speak
2012-07-27 08:03:27 utc jmettraux ok
2012-07-27 08:03:46 utc hartog and in the events of a process I want to trigger stuff
2012-07-27 08:04:08 utc jmettraux ok
2012-07-27 08:04:26 utc hartog I've just peeked at the pre_msg experiment
2012-07-27 08:04:46 utc jmettraux too bad
2012-07-27 08:04:52 utc hartog I think it is bad for the same reasons my pull request was bad
2012-07-27 08:05:08 utc jmettraux ok
2012-07-27 08:05:27 utc hartog http://reasonablecode.com/blog/2012/05/23/activerecord-callbacks-are-unreasonable/
2012-07-27 08:05:36 utc hartog ^ is what convinced me
2012-07-27 08:06:36 utc jmettraux so what do you suggest?
2012-07-27 08:07:14 utc hartog let me gist up what I am trying to do now; hang in there
2012-07-27 08:10:57 utc jmettraux (for thread accounting purpose, this chat is a complement to https://github.com/jmettraux/ruote/pull/54 )
2012-07-27 08:11:47 utc hartog this was my stab this morning : https://gist.github.com/3186751
2012-07-27 08:12:32 utc hartog but I do feel that is a bit low-level'ish
2012-07-27 08:12:48 utc jmettraux since my experimental branch is bad, then this gist is bad
2012-07-27 08:13:16 utc hartog no; because you want to tamper with the msg in pre_msg
2012-07-27 08:13:27 utc hartog I would keep it read-only
2012-07-27 08:14:05 utc jmettraux so if I remove the pre_msg thinggy, I end up with the same solution as you
2012-07-27 08:14:34 utc hartog Great minds think alike ;)
2012-07-27 08:14:40 utc jmettraux so what's new here?
2012-07-27 08:14:52 utc hartog the problem I have with it; is the fact that I receive a message
2012-07-27 08:15:09 utc hartog If I approach ruote from a distance
2012-07-27 08:15:22 utc hartog I get a process, some participants, and workitem
2012-07-27 08:15:57 utc hartog underneath it all, it is driven by messages - but I don't really care about those
2012-07-27 08:16:18 utc hartog I want to know; which process launched, with what workitem
2012-07-27 08:16:34 utc jmettraux that's a message (an event)
2012-07-27 08:19:44 utc hartog technically; but not semantically
2012-07-27 08:19:52 utc hartog ACTION gists some more
2012-07-27 08:25:50 utc hartog i've added favourable.rb to https://gist.github.com/3186751
2012-07-27 08:26:24 utc hartog it should be noted that workitems, errors, etc. should be immutable
2012-07-27 08:26:48 utc jmettraux why "technically; but not semantically" ?
2012-07-27 08:26:57 utc jmettraux (I'll get back to your gist later)
2012-07-27 08:27:47 utc hartog because, as a process developer, i am not (should not be?) interested in the messages the system uses to get the workflow going
2012-07-27 08:28:05 utc hartog i am interested in the workflow
2012-07-27 08:28:39 utc hartog and the workitem
2012-07-27 08:28:50 utc jmettraux semantically not a message?
2012-07-27 08:29:08 utc jmettraux ok, let's forget that
2012-07-27 08:29:20 utc jmettraux so you want a sugar coated observer?
2012-07-27 08:29:46 utc hartog exactly
2012-07-27 08:30:04 utc jmettraux is it a good idea to promote it to other ruote users?
2012-07-27 08:31:53 utc jmettraux I don't want to promote such thing to people that don't yet understand basic process definitions and participants
2012-07-27 08:32:11 utc jmettraux observers are advanced stuff
2012-07-27 08:32:14 utc hartog I would
2012-07-27 08:33:00 utc hartog a question any manager would ask; can it send me an email when it fails
2012-07-27 08:33:16 utc jmettraux good point
2012-07-27 08:33:31 utc jmettraux and on_flunk doesn't solve it
2012-07-27 08:33:58 utc jmettraux and before the user goes to on_error_intercepted, I expect him to know about the :on_error attribute
2012-07-27 08:34:05 utc jmettraux and engine.on_error
2012-07-27 08:34:53 utc jmettraux I think your sugar coated observer would look great with a nice piece of documentation around it
2012-07-27 08:34:56 utc jmettraux as an example
2012-07-27 08:35:02 utc hartog Ruote is a massive framework; expecting users to grasp all the concepts and know about all the possible options is a bit unfair perhaps
2012-07-27 08:36:11 utc hartog it *must* be documented and people should be forewarned about the complexity of observers
2012-07-27 08:36:32 utc jmettraux ok
2012-07-27 08:36:39 utc hartog perhaps even a summary or link of the reasonablecode blog should be added
2012-07-27 08:36:42 utc jmettraux so writing more code won't help
2012-07-27 08:37:05 utc hartog comes the next question; in ruote? or as a gem?
2012-07-27 08:38:01 utc jmettraux in the documentation
2012-07-27 08:39:43 utc hartog meaning? you would document the sugar coated example?
2012-07-27 08:39:49 utc jmettraux yes
2012-07-27 08:40:41 utc jmettraux as it stands it's hartog-oriented
2012-07-27 08:40:52 utc hartog :)
2012-07-27 08:40:55 utc jmettraux on_flunk and on_step don't make sense
2012-07-27 08:41:25 utc hartog on_step does not make sense - granted
2012-07-27 08:41:53 utc jmettraux I'd be OK for a subscriber example
2012-07-27 08:42:06 utc jmettraux a base class, like I did in the my experimental branch
2012-07-27 08:42:20 utc jmettraux then we could have a "hand holding" subscriber
2012-07-27 08:42:39 utc jmettraux with nice on_launch(pdef, wfid, fields, variables)
2012-07-27 08:43:34 utc hartog seems very reasonable to me
2012-07-27 08:44:04 utc hartog should I poor it into a gem? keeping it away from ruote to begin with?
2012-07-27 08:44:30 utc hartog (because I am going to write such code real-soon-now anyway)
2012-07-27 08:45:02 utc jmettraux it doesn't need to go into a gem
2012-07-27 08:46:50 utc hartog in that case; you can expect another pull-request to be rolling in ;)
2012-07-27 08:47:16 utc jmettraux ok
2012-07-27 08:47:27 utc jmettraux as usual I'll be very strict
2012-07-27 08:47:35 utc hartog i'll try to commit (and push) often so you can comment on my commits and steer me
2012-07-27 08:47:37 utc jmettraux any amqpism will be ruled out
2012-07-27 08:47:47 utc hartog hehehe
2012-07-27 08:48:01 utc jmettraux you don't need to commit too often, it's a very limited thing ;-)
2012-07-27 08:48:28 utc hartog (as a side note; amqp is horrible beast)
2012-07-27 08:49:03 utc jmettraux somehow, by amqpism, I mean things like thinking that all workitems come back to the engine via a receiver
2012-07-27 08:49:08 utc jmettraux local participants do exist
2012-07-27 08:49:13 utc jmettraux ok
2012-07-27 08:49:15 utc jmettraux then great
2012-07-27 08:49:48 utc jmettraux my ProcessSubscriber will be a great model
2012-07-27 08:49:57 utc jmettraux ;-)
2012-07-27 08:50:12 utc jmettraux need to run now, ttyl
2012-07-27 08:51:41 utc hartog kthx!
2012-07-27 08:51:45 utc hartog bye now!
2012-07-27 10:08:57 utc jmettraux back
2012-07-27 19:39:06 utc Gurpartap anyone here willing to give a 2 min kickstart for ruote?
2012-07-27 19:39:15 utc Gurpartap i'm unable to get my head around it :/
2012-07-27 19:40:36 utc Gurpartap i'm using redisstorage so that i can have remote servers participate
2012-07-27 19:41:03 utc Gurpartap but i have some practical coding question around how exactly to get started with that
2012-07-27 19:41:25 utc Gurpartap halp! :P
2012-07-27 21:19:03 utc jmettraux Gurpartap: hello, welcome to #ruote
2012-07-27 21:19:20 utc Gurpartap hey :)
2012-07-27 21:20:02 utc jmettraux if there is no one answering here, use the mailing list https://groups.google.com/forum/?fromgroups#!forum/openwferu-users
2012-07-27 21:20:39 utc jmettraux ready to help now anyway
2012-07-27 21:20:41 utc Gurpartap ah
2012-07-27 21:21:33 utc Gurpartap jfyi, sexp has a newer version, that somehow doesn't let me install ruote from rubygems
2012-07-27 21:22:02 utc Gurpartap unless, i guess, i point it to use previous sexp version.
2012-07-27 21:22:12 utc jmettraux jfmi, what's the error message?
2012-07-27 21:22:15 utc Gurpartap i ended up using ruote from git
2012-07-27 21:22:22 utc jmettraux great
2012-07-27 21:22:57 utc Gurpartap https://gist.github.com/3190499
2012-07-27 21:23:29 utc jmettraux ok, understood, checking the .gemspec
2012-07-27 21:25:12 utc jmettraux via sourcify... https://rubygems.org/gems/sourcify
2012-07-27 21:25:19 utc Gurpartap ah
2012-07-27 21:25:34 utc jmettraux ok, anyway, it's great, using from git is the recommended way until ruote 2.3.0 is out
2012-07-27 21:25:43 utc Gurpartap alright
2012-07-27 21:26:00 utc Gurpartap so my query starts with simple "is it possible?" stuff
2012-07-27 21:26:43 utc Gurpartap i learnt about the difference between state machine and workflow (i have been using multiple state machine gems in past, and understand a workflow based on that)
2012-07-27 21:27:43 utc Gurpartap in this particular case, i'm provisioning an application on a specific server (and before that, provisioning the server as well, if it isn't already)
2012-07-27 21:27:55 utc Gurpartap s/an application/applications/
2012-07-27 21:29:17 utc Gurpartap How I understand about employing ruote is that each server can have a ruote worker, with the coordinating ruote engine/dashboard on the main server
2012-07-27 21:29:52 utc jmettraux each worker can also have a dashboard
2012-07-27 21:30:10 utc Gurpartap I'm naive to the engine/dashboard concept
2012-07-27 21:30:13 utc jmettraux you're right
2012-07-27 21:30:27 utc Gurpartap ok great
2012-07-27 21:31:24 utc Gurpartap so the workflow invocations happen through a rails project.
2012-07-27 21:31:48 utc Gurpartap 1. Why does route-kit project exist? I don't see the benefit (yet)
2012-07-27 21:32:22 utc jmettraux it's half an Rack integration example, half a ruote admin tool
2012-07-27 21:32:34 utc Gurpartap 2. What exactly is a dashboard (esp since there can be a "dashboard per worker" as well, which confuses me)
2012-07-27 21:33:24 utc Gurpartap (i have skimmed through ruote site's docs, but sometimes it takes another read to understand :)
2012-07-27 21:33:39 utc jmettraux :-)
2012-07-27 21:34:02 utc jmettraux ok, both the worker and the dashboard plug themselves into a [common] storage
2012-07-27 21:34:25 utc jmettraux the worker grabs msgs (orders) and schedules and executes them
2012-07-27 21:34:48 utc jmettraux executing a schedule is simply picking up a schedule whose time has come and turning it into a msg (order)
2012-07-27 21:35:20 utc jmettraux so the worker works alone, executing workflow instances pieces by pieces
2012-07-27 21:35:24 utc jmettraux the dashboard
2012-07-27 21:35:47 utc jmettraux is a set of high-level methods, like #launch #cancel #re_apply #process(wfid)
2012-07-27 21:36:11 utc jmettraux used by other applications to a) give work to ruote b) query ruote about the ongoing work
2012-07-27 21:36:29 utc jmettraux that's about it
2012-07-27 21:36:35 utc Gurpartap i see.
2012-07-27 21:37:10 utc Gurpartap why does a worker get access to a dashboard? (i might learn this from writing some code though, i guess)
2012-07-27 21:37:33 utc Gurpartap i think i can make that out
2012-07-27 21:40:33 utc Gurpartap ok, i now have some practical code questions
2012-07-27 21:41:16 utc jmettraux well, a worker doesn't get access to a dashboard
2012-07-27 21:45:28 utc jmettraux (just realized that the latest commit introduced such a "worker talks to dashboard" thing, working on remove it now)
2012-07-27 21:47:47 utc jmettraux (fixed https://github.com/jmettraux/ruote/commit/9b65d75ad39a525e7d13182eddc050198531b860 )
2012-07-27 22:32:46 utc Gurpartap meh
2012-07-27 22:32:54 utc Gurpartap confused coding it
2012-07-27 22:43:15 utc Gurpartap https://gist.github.com/3190784
2012-07-27 22:44:26 utc Gurpartap When RuoteDashboard is initialized as a worker in the [rails] app, why does it end up processing participants, which I would want to run on a separate shell/machine
2012-07-27 22:45:11 utc Gurpartap i udnerstand that it uses sourcify to execute things, but how about if i wanted the code to only run on a specific worker (when there are several workers on separate machines)
2012-07-27 22:45:19 utc Gurpartap s/udnerstand/understand/
2012-07-27 22:48:36 utc Gurpartap jmettraux:
2012-07-27 22:57:55 utc jmettraux sorry, it doesn't use sourcify to execute things
2012-07-27 22:58:20 utc jmettraux it uses sourcify to turns some ruby blocks into source code
2012-07-27 22:58:48 utc jmettraux it has nothing to do with workers picking jobs
2012-07-27 23:00:07 utc jmettraux ok, back to your question
2012-07-27 23:00:57 utc jmettraux when you instantiate the Dashboard with a nested Worker, well then there is a worker
2012-07-27 23:01:17 utc jmettraux and that worker, like any other worker is given the opportunity to perform work
2012-07-27 23:01:47 utc jmettraux if you don't want the worker next to your dashboard to do work, then don't instantiate it
2012-07-27 23:02:08 utc jmettraux you can write RuoteDashboard = Ruote::Dashboard.new(RuoteStorage)
2012-07-27 23:02:11 utc jmettraux it's OK
2012-07-27 23:02:52 utc jmettraux you can also write dashboard = Ruote::Dashboard.new(storage); worker = Ruote::Worker.new(storage)
2012-07-27 23:03:32 utc jmettraux to make it brief: you are not forced to instantiate a worker each time you instantiate a dashboard
2012-07-27 23:03:40 utc Gurpartap ok i see
2012-07-27 23:08:51 utc Gurpartap i did not know that any worker can do any work
2012-07-27 23:09:11 utc Gurpartap so i have to re-imagine things
2012-07-27 23:09:42 utc jmettraux there are ways for workers to accept only some participant work
2012-07-27 23:10:05 utc jmettraux but otherwise it's good to have workers with equal capabilities
2012-07-27 23:10:11 utc jmettraux it's easier to manage