On Sat, Sep 25, 2010 at 10:39:15PM +0900, John Mettraux wrote:
>
> On Sat, Sep 25, 2010 at 10:45:49AM +0000, Hartog C. de Mik wrote:
> > On Sat, Sep 25, 2010 at 07:28:37PM +0900, John Mettraux wrote:
> > > >
> > > > Solvability:
> > > > - of problems due to lack of documentation
> > >
> > > I have to protest here, ruote is not lacking documentation. I'm
> > > always struggling to bring more documentation on the table and
> > > always saying "if a point in the documentation is not clear, please
> > > say so".
> >
> > Nothing personal! ;-) Ruote is the best documented of the components
> > used, my main concern where the amqp related components. Yes; the have
> > rdoc for (almost) every function used, and if you read all of them you
> > can build a notion of how the objects and components are to interface
> > and depend on one and other.
> >
> > It is however very scattered, and requires a lot of creativity of the
> > person with the problem to find the right piece of information.
> >
> > As an example; it took a lot of inspecting AMQP.logging to figure out
> > that the daemon-kit generated classes responded to no queue at
> > all.
> >
> > Finding out where and how to set the reply queue was a matter of
> > using the right search terms in google, which in term require
> > knowledge of how message queues work. If you are new to this domain,
> > it is very hard to get answers from just the documentation. Imho the
> > documentation is then failing to be informative enough.
> >
> > And I agree - no matter how much documentation you write, there will
> > always be complaints.
>
> Point taken for the ruote-amqp documentation. I will try to find some time to
> make it better (though I am not the original author).
>
> I have had a look at your ping/pong example.
>
> http://github.com/coffeeaddict/ruote-amqp-ping-pong
>
> Congratulations for all the work ! I feel guilty because most of the work was
> induced by the lack of documentation in ruote[-amqp].
>
> I have a few small remarks, please note that I completely understand that
> some of those remarks concern misunderstandings induced by lacks in
> documentation (and not lacking documentation) for which, as the project
> leader, I am responsible.
>
> So :
>
> - Storing the data into ruote_worker/ is a bit confusing for me, I was
> expecting to find some ruote worker code related in there. Maybe ruote_data/
> or ruote_development_data/ ruote_production_data/ is a better folder name.
Good point! Fixed that.
> - The error_logger participant isn't really necessary, if a process gets into
> an error, the process is still queryable :
>
> errs = engine.errors
> if errs.size > 0
> puts "there are processes with errors :"
> errs.each do |err|
> puts "process #{err.wfid}"
> end
> end
Ah, that's usefull. Refactored.
> - It would be more DRY to reduce the ping and the pong components to
> one component that you instantiate two times (ping and pong)
Yes, it would be more dry, but I did this willingly and knowingly; The
intent of the example is not be DRY, but to be examplatory. And having
2 seperate daemon-kit participants is (imho) more informative then
having one which can do both.
> - The process definition could be a bit simpler, there is one point
> with which I was not really following the original ruote-amqp
> author, but I'd prefer avoiding putting AMQP configuration details
> in a process definition. It's better to pass that configuration when
> registering the participants or via process variables. You are
> elegantly hiding that in two (ping and pong) subprocesses, but I'd
> really love people not to have to do that.
I will fix this soon; I must first figure what happens when moving
around these options. I fully agree that all these options should not
be in the process definition; that should be kept as clean of
'configuration' as possible and easily be editable by the
BPM-consultant-three-doors-down.
> - It would be nice to have an orientation in the README.rdoc that
> indicates where is what.
Fixed that.
> Your example directly goes ruote + ruote-amqp + AMQP + RabbitMQ. For fun, I
> went back to ruote only and produced this ping/pong example :
>
> ( http://gist.github.com/596822 )
>
> ---8<---
> require 'rubygems'
> require 'ruote'
>
> pdef = Ruote.process_definition do
> repeat do
> ping # mister ping, please shoot first
> pong
> end
> end
>
> class Opponent
> include Ruote::LocalParticipant
>
> def initialize (options)
> @options = options
> end
>
> def consume (workitem)
> puts @options['sound']
> reply_to_engine(workitem)
> end
> end
>
> engine = Ruote::Engine.new(Ruote::Worker.new(Ruote::HashStorage.new))
>
> engine.register_participant :ping, Opponent, 'sound' => 'ping'
> engine.register_participant :pong, Opponent, 'sound' => 'pong'
>
> wfid = engine.launch(pdef)
>
> sleep 5 # five seconds of ping pong fun
>
> engine.cancel_process(wfid) # game over
> --->8---
>
> It orchestrates a tennis table exchange between ping and pong for 5 seconds.
A lot cleaner than mine :-)
Will be pushing my updates to github shortly.
Grtz,
Hartog.
--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to [email protected]
to unsubscribe : send email to [email protected]
more options : http://groups.google.com/group/openwferu-users?hl=en
