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 |