ruote-kit configuration rework

[John Mettraux]

Hello,

lately, with the help of Torsten, I've been working on ruote-kit.

I'd like to change the way ruote-kit is configured. It currently wraps ruote's core configuration in a too inflexible way.

The original intent of Kenneth was to make it easy to do :

RuoteKit.configure do |conf|
conf.run_worker = true
conf.register do
participant "alpha", MyAlphaParticipant, :flavour => 'vanilla'
catchall
end
end

(the register block courtesy of Torsten).

This would create a ruote-kit (RuoteKit.engine) bould to a default filesystem storage. You could use a HashStorage by doing

RuoteKit.configure do |conf|
conf.mode = :transient
end

But then, we got a ruote-kit stuck with only two modes :file_system (the default) and :transient.

I added a Configuration#set_storage method to do things like

conf.set_storage(
Ruote::Couch::CouchStorage,
uri.host, uri.port,
'couch_prefix' => "roma_#{Rails.env}")

There is then two or three options to decide whether to run an engine (in fact they never run) and to run workers.

All is good, but IMO, ruote's configuration is sufficiently easy and convenient not to be hidden.

RuoteKit.engine = Ruote::Engine.new(
Ruote::Worker.new(
Ruote::FsStorage.new('ruote_work')))
RuoteKit.engine.register do
participant "alpha", MyAlphaParticipant, :flavour => 'vanilla'
catchall
end

The convention here is that the engine is located in the RuoteKit.engine 'singleton'.

The trick here is that I will port the register block configuration from ruote-kit to ruote.

(BTW, there is a new way of registering participants, inspired by Don French on IRC :

http://github.com/jmettraux/ruote/commit/b6976e508b6d7d0f7801669186a84bf77a706dda

)

I've been working on simplifying ruote-kit's configuration this week-end :

http://github.com/jmettraux/ruote-kit/

But I really want to make it simpler. I also don't want to have to maintain a doc for configuring ruote-kit that cannot heavily borrow/reference ruote's configuration doc.

Comments ?

--
John Mettraux - http://jmettraux.wordpress.com

[Torsten Schönebaum]

John wrote:

[about configuration in RuoteKit]

> All is good, but IMO, ruote's configuration is sufficiently easy and
> convenient not to be hidden.
>
> RuoteKit.engine = Ruote::Engine.new(
> Ruote::Worker.new(
> Ruote::FsStorage.new('ruote_work')))
> RuoteKit.engine.register do
> participant "alpha", MyAlphaParticipant, :flavour => 'vanilla'
> catchall
> end
>
> The convention here is that the engine is located in the RuoteKit.engine 'singleton'.
>
> The trick here is that I will port the register block configuration
> from ruote-kit to ruote.
>

> Comments ?

In my opinion, this is a great idea. I would suggest a default fallback
if the user forgets to set RuoteKit.engine, though.

Thanks,
Torsten

[John Mettraux]

2010/7/12 Torsten Schönebaum <torsten.s...@web.de>:

Hello Torsten,

for now, I was thinking about "letting it break fast".

Cheers,

[Torsten Schönebaum]

Am Montag, den 12.07.2010, 16:58 +0900 schrieb John Mettraux:
> 2010/7/12 Torsten Schönebaum <torsten.s...@web.de>:
> > John wrote:
> >
> > [about configuration in RuoteKit]
> >
> >> All is good, but IMO, ruote's configuration is sufficiently easy and
> >> convenient not to be hidden.
> >>
> >> RuoteKit.engine = Ruote::Engine.new(
> >> Ruote::Worker.new(
> >> Ruote::FsStorage.new('ruote_work')))
> >> RuoteKit.engine.register do
> >> participant "alpha", MyAlphaParticipant, :flavour => 'vanilla'
> >> catchall
> >> end
> >>
> >> The convention here is that the engine is located in the RuoteKit.engine 'singleton'.
> >>
> >> The trick here is that I will port the register block configuration
> >> from ruote-kit to ruote.
> >>
> >> Comments ?
> >
> > In my opinion, this is a great idea. I would suggest a default fallback
> > if the user forgets to set RuoteKit.engine, though.
>

> for now, I was thinking about "letting it break fast".

Having thought about that, I believe you're right, even without the
quotation marks ;-) Voting for a nice exception message now.

Yours,
Torsten

[John Mettraux]

Hello,

On this "let's make participant registration better / less obscure", I've just added two methods to Engine :

http://github.com/jmettraux/ruote/commit/7cca2c77a7fceb151f7a3fe787b388425fa804c3

Here is an example usage :

---8<---
engine.register_participant :alpha, MyParticipant, 'message' => 'hello'

# interrogate participant list
#
list = engine.participant_list
participant = list.first
p participant.regex
# => "^alpha$"
p participant.classname
# => "MyParticipant"
p participant.options
# => {"message"=>"hello"}

# update participant list
#
participant.regex = '^alfred$'
engine.participant_list = list
--->8---

The participant list as whole can thus be manipulated (and checked for consistency).

I've also revived (added tests for) :require_path and added the :load_path friend :

http://github.com/jmettraux/ruote/commit/d00fdd7ebf9e7e65c129d15b9e879d5bd0ee6340

---8<---
engine.register_participant(
:alpha,
'Parts::MyParticipant',
'require_path' => 'parts/my_participant.rb',
'flavour' => 'mango')
#
# each time the worker has to deliver to this participant, it will
# require('parts/my_participant.rb') which will return immediately
# if the file is already loaded

engine.register_participant(
:alpha,
'Parts::MyOtherParticipant',
'load_path' => 'parts/my_other_participant.rb',
'flavour' => 'lychee')
#
# each time the worker has to deliver to this participant, it will
# load('parts/my_other_participant.rb') which will always read and eval
# the ruby file (up-to-date implementation will be used)
--->8---

I have removed the register_from_dir() for now, I want to re-introduce it at some point (maybe in the form of a participant for better modularity).

---8<---
engine.register_participant(
'auto-.+',
Ruote::DirParticipant,
:path => 'participants/auto/')
--->8---

That could keep the participant-list fat-free and let people creatively extend / take inspiration from Ruote::DirParticipant.

The register(&block) idea is still in the works (the port from ruote-kit to ruote).

I'm also thinking about letting participant refuse to handle a workitem (which could bring interesting behaviours when iterating the participant list (or maybe this is too complicated...)