ruote log_2010-06-25

2010-06-25 04:55:13 utc jmettraux lbt: what's wrong with http://github.com/jmettraux/ruote/blob/ruote2.1/lib/ruote/context.rb#L127 ?
2010-06-25 06:08:22 utc lbt it hurts my head..... :)
2010-06-25 06:08:52 utc jmettraux lbt: morning, ah ok
2010-06-25 06:09:36 utc lbt and, tbh, I think it should be documented there and at l159 :)
2010-06-25 06:09:39 utc lbt morning
2010-06-25 06:10:07 utc jmettraux OK, I will add a note
2010-06-25 06:10:21 utc lbt I woke up early thinking about remote registration
2010-06-25 06:10:36 utc lbt and wondering if one git repo could hold multiple gems?
2010-06-25 06:10:55 utc jmettraux it can
2010-06-25 06:11:00 utc lbt it would be nice to have r-a-client
2010-06-25 06:11:23 utc jmettraux not sure about it
2010-06-25 06:11:23 utc lbt which has an Engine in it
2010-06-25 06:11:31 utc jmettraux ?
2010-06-25 06:11:37 utc lbt which allows registration
2010-06-25 06:12:00 utc jmettraux remote registration : I think it's not necessary,
2010-06-25 06:12:23 utc jmettraux you can do all the multiplexing you want over the amqp fence
2010-06-25 06:12:57 utc lbt http://github.com/lbt/ruote-amqp/commit/a9c702b056fa8f07b4e63465a779b27c9d2864a4
2010-06-25 06:13:28 utc jmettraux seen
2010-06-25 06:13:53 utc lbt that's a hack branch as I won't be at my desktop today :)
2010-06-25 06:14:41 utc lbt http://github.com/lbt/ruote-amqp-pyclient/commit/145d1dc43a54643613f060e2995e5b8f67aa91a4
2010-06-25 06:14:58 utc jmettraux the two commits seem not consistent
2010-06-25 06:15:04 utc lbt they're not
2010-06-25 06:15:28 utc lbt I wrote http://gist.github.com/452509
2010-06-25 06:15:36 utc lbt but realised that was ugly
2010-06-25 06:16:25 utc lbt then I went to bed
2010-06-25 06:17:04 utc lbt one objective kennethkalmer had was to not require all of ruote in a remote d-k client
2010-06-25 06:17:20 utc lbt me too of course for a python remote
2010-06-25 06:17:42 utc lbt but I want to participate, and then register and launch processes
2010-06-25 06:17:52 utc lbt eventually query too
2010-06-25 06:19:51 utc lbt anyhow... just mentioning what I'm doing and listening to make sure there are no objections
2010-06-25 06:19:55 utc jmettraux ruote-amqp's goal is to pass workitems from the engine to the real participants over AMQP
2010-06-25 06:20:23 utc jmettraux register and query are a bit off
2010-06-25 06:20:37 utc lbt OK, but launching is the other way around
2010-06-25 06:20:58 utc jmettraux so ?
2010-06-25 06:20:58 utc lbt and if I can launch... I need to be able to register something to launch...
2010-06-25 06:21:08 utc lbt no?
2010-06-25 06:21:10 utc jmettraux the other way around is still parallel
2010-06-25 06:21:20 utc jmettraux no
2010-06-25 06:21:35 utc jmettraux well
2010-06-25 06:21:39 utc jmettraux in your implementation maybe
2010-06-25 06:22:02 utc lbt I may be using it differently?
2010-06-25 06:22:16 utc lbt I have a semi-persistent engine in my approach
2010-06-25 06:23:16 utc jmettraux 15:18 jmettraux: remote registration : I think it's not necessary,
2010-06-25 06:23:16 utc jmettraux 15:18 jmettraux: you can do all the multiplexing you want over the amqp fence
2010-06-25 06:23:39 utc lbt true... I could send raw amqp at it... ?
2010-06-25 06:23:57 utc lbt but then I could register locally by writing into the fs db :)
2010-06-25 06:24:08 utc jmettraux so complicated....
2010-06-25 06:24:12 utc lbt it's a convenience?
2010-06-25 06:24:26 utc jmettraux you're shooting yourself in both foot
2010-06-25 06:24:30 utc jmettraux feet
2010-06-25 06:24:42 utc jmettraux 1 amqp participant is sufficient
2010-06-25 06:25:08 utc jmettraux then, based on the workitem.participant_name or a field, you can "route" to the real consumption code
2010-06-25 06:25:16 utc jmettraux no need to register participant on the fly
2010-06-25 06:25:23 utc jmettraux participants
2010-06-25 06:25:30 utc lbt p.register("revs_update", {'queue':'revs_update'})
2010-06-25 06:26:20 utc lbt so if I create a new remote participant, how do I use it
2010-06-25 06:27:24 utc jmettraux you don't
2010-06-25 06:27:39 utc jmettraux you use 1 participant
2010-06-25 06:28:30 utc lbt not following
2010-06-25 06:28:53 utc jmettraux in your consumption code, you're not bound to implement 1 reaction
2010-06-25 06:29:05 utc lbt ah...
2010-06-25 06:29:08 utc jmettraux you can have a little routing table and fire any code you want
2010-06-25 06:29:24 utc lbt I intende to have multiple remote participants
2010-06-25 06:30:13 utc lbt probably almost all non-trivial ones will be r-a
2010-06-25 06:34:40 utc jmettraux don't throw too much code at it
2010-06-25 06:35:10 utc lbt *nod* ... I'm not trying to be difficult ... honest :)
2010-06-25 06:35:36 utc lbt it just seemed natural... possibly because I'm having to do a python client
2010-06-25 06:35:40 utc jmettraux no worries, I understand the enthusiasm, I'm trying not to have too much code to maintain
2010-06-25 06:36:31 utc lbt good ... I really don't want to cause problems and what have you
2010-06-25 06:36:55 utc lbt let me hack on the idea a little more... see where it goes... and how to keep it sane
2010-06-25 06:37:21 utc lbt an I pushed to a hack-branch to be clear that this isn't for master at the moment
2010-06-25 06:37:47 utc lbt btw... the 'persistent engine' deployment model...
2010-06-25 06:38:12 utc lbt is that a normal/expected approach?
2010-06-25 06:38:57 utc jmettraux most of the people I've met expect their data / processes to be still there after the engine process restarts
2010-06-25 06:39:12 utc lbt *nod*
2010-06-25 06:39:24 utc jmettraux a transient engine is fun and possible
2010-06-25 06:39:38 utc jmettraux I use it for testing all the time
2010-06-25 06:39:41 utc lbt my planned deployment expects a lot of automated processes
2010-06-25 06:39:58 utc lbt so having a mainly persistent engine is useful
2010-06-25 06:40:16 utc lbt the restart is expected to be downtime or a fault
2010-06-25 06:40:42 utc lbt and tolerance to that is a superb side-effect
2010-06-25 06:41:39 utc lbt the other aspect is that I think the persistent engine is more of a persistent r-a Receiver
2010-06-25 06:42:19 utc lbt and I'm expecting enough process activity through it that restarting the engine will be wasteful
2010-06-25 06:43:41 utc jmettraux ok
2010-06-25 06:44:40 utc lbt right... I'm hoping to show ruote to some other people today too.
2010-06-25 06:44:48 utc jmettraux cool
2010-06-25 06:44:54 utc lbt the education website I mentioned :)
2010-06-25 06:45:59 utc lbt oh, and I heard from LWN ... they didn't want an article on Ruote alone but may like one on MeeGo and how it uses it.... which I don't agree with but...
2010-06-25 06:47:02 utc jmettraux LWN stands for Linux ;)
2010-06-25 06:47:07 utc lbt Jake said : "Thanks for thinking of us, but this doesn't really seem like something in our sweet spot."
2010-06-25 06:47:15 utc jmettraux isn't it ?
2010-06-25 06:47:22 utc lbt it is IMHO
2010-06-25 06:47:24 utc lbt 100%
2010-06-25 06:48:33 utc lbt I'll pursue it though :)
2010-06-25 06:49:08 utc jmettraux thanks for the investment !
2010-06-25 06:50:00 utc lbt well, I think ruote is very impressive ... I'm investing because I think it deserves it
2010-06-25 06:50:09 utc jmettraux :)
2010-06-25 06:51:07 utc lbt did I mention I used to be an architect at BT? It may help understand why I think about certain things in an 'enterprisey' way.
2010-06-25 06:51:16 utc jmettraux :)
2010-06-25 06:51:31 utc lbt but KISS... is really important too
2010-06-25 06:52:09 utc jmettraux yes !
2010-06-25 06:53:31 utc lbt just want to make sure you understand that I understand :)