Hello Gonzalo,
thanks for testing the dm expstorage.
I have committed a potential fix
http://github.com/jmettraux/ruote/commit/97bdc8c7103f6e61a2f3ea67fdf3f5ead43a0e8f
Maybe this expstorage is a bit too experimental for ruote 0.9.x. It's
much more tested for ruote 2.0 though.
Tell me how it works for you.
A quick question, I'm curious ;) Why are you guys trying to move to
rdbms persistence ?
Thanks a lot for the report, cheers,
--
John Mettraux - http://jmettraux.wordpress.com
Nice !
BTW, if I could help you to migrate to ruote 2.0, what would you need
? Would you need the equivalent of ruote-rest ?
As you might know, our backend development is mainly focused on
route-rest. As Nando and I told you before, we've done some
improvements on the authentication layer, aka "Spanish Authentication"
:-)
On the other hand, we have extended ArWorkitem so that it can handle
users, groups and authorization primitives: "pick, release, delegate
(to_group and to_user) and undo (a kind of wi_fields rollback to the
'consume' state)". Last week, Nando enabled Jabber PubSub capabilities
to these operations and to ArParticipant's consume, thus avoiding the
need to poll the resource "/workitems" from the client.
The original ArWorkitem has been left unharmed, as these authorization
behaviors are dinamically loaded after ruote-rest/lib/res/workitems.rb
performs a find_workitem, using ActiveRecord's "after_find" callback:
---- begin snip ----
class ArWorkitem
....
def after_find
unless self.extended_behaviors.nil?
require 'openwfe/extras/misc/behaviors'
self.extended_behaviors.split(',').each do |extension|
self.class_eval "include OpenWFE::Extras::Behaviors::#{extension}"
end
end
end
--- end snip ---
As written above, these "behaviors" are just auth methods and pubsub
stuff, used by our two new participants:
---- begin snip ---
class ArAuthParticipant < ArParticipant
...
def consume
...
ArWorkitem.from_owfe_workitem(workitem, @store_name, @assigned_to,
@owner_group, nil, ['ArSimpleAuthorization'])
...
class JabberArAuthParticipant < ArAuthParticipant
...
def consume
...
ArWorkitem.from_owfe_workitem(workitem, @store_name, @assigned_to,
@owner_group, @pubsub_uuid, ['ArPubSubAuthorization'])
...
---- end snip ---
Accordingly, we had to add more fields to the original ar_workitems table.
Worth mentioning is the extension we've made to Kenneth's
extras/misc/jabber_common.rb so that it includes methods to deal with
a PubSub service, as well as the changes made to xmpp4r-simple itself.
We really don't know if this approach is correct, given that we have
closely bound ArWorkitem with the REST layer, but all in all, this is
the famous "last mile" that we love so much about your project. We'll
post the complete patches during the week so that you can give us some
feedback, via mailing-list or #ruote irc.
So, answering your question, since we've developed participants that
are so closely coupled with the REST layer, it would be great that
ruote-kit would be compatible with them, or that you could tell us how
to adapt them to the upcoming changes. We have in mind that
Ruote2.0/ruote-kit is the way to go, but we are not in a hurry. Our
next few internal milestones will be still based on ruote-rest, but in
the meantime we will continue contributing to this community and
refactoring our code.
Best regards,
//Gonzalo and Nando
2009/8/30 John Mettraux <jmet...@openwfe.org>: