On 02/11/11 13:53, Ed Bartosh wrote:
-----Original Message----- OK - currently we have a ruote-process plugin
which sends out a certain message; what you're suggesting is more of a
generic amqp plugin.
Yes.
We'd then need a discrete AMQP->ruote daemon running somewhere which
listens on that queue, wraps the ruote envelope around the event data and
resends it - so that may be possible. I'd prefer to take an approach where
we permit per-destination message generators.
That would make solution less generic from my point of view. I'd prefer to
have ruote or anything like that on the other side of AMQP.
A nicer plugin would permit multiple connections and multiple message
formats:
The msg_maker would take a $paramRef and make something like a json or XML
message. For BOSS/Ruote, the msg_maker would make a json with some extra
envelope.
I don't think this is a good idea to have anything like that on plugin side.
Plugin should send simple events to AMQP, period. That would keep it simple,
fast and decoupled from any workflow engine or another consumer-specific
details.
Yeah - but what if someone else's AMQP client would like a json msg ? or an XML
msg?
And don't forget ... for BOSS, AMQP is the ruote transport; ruote is not a
generic AMQP client :) so I have to send messages that are understood.
On the second point I don't see that my proposal is any heavier since you'd
probably just default to using an event2json() msgmaker and my solution would
need to define an event2boss() msgmaker.
I see event traffic as generating one of the higher AMQP message rates - so
doubling that by requiring an intermediate AMQP translator/relay is not ideal.
The reason I don't just say "oh, lets have 2 plugins" is that the difference
really is tiny - I need an extra optional function reference in the definition
that formats the message - that can default to json, trivially support XML and
easily wrap some envelope for ruote.
Whilst we're at it, if we're going to do this properly then we need to
think about availability.
[snip bit about reliability]
That's another story. Let's discuss it after first part is designed and
implemented.
Sure. I'm trying to avoid the "oops, I didn't think of that and now we're in
production and we can't change it" syndrome - as long as we know what direction
we're going.
David
--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
_______________________________________________
MeeGo-distribution-tools mailing list
[email protected]
http://lists.meego.com/listinfo/meego-distribution-tools
