On Tue, Apr 7, 2009 at 4:05 AM, Nando <[email protected]> wrote:
>
> First off, let me explain a bit about our current project. We work for
> a start-up that develops products for the international commerce
> sector. Our original plan was to use OpenESB, but after a while we
> came back to our senses and fled SOA and BPEL. We wanted something
> simple, developer-friendly and RESTful. So after investigating for a
> while, we found ruote and route-rest. During the past three months,
> we've been adapting both of them to meet our needs.
>
> So our feedback on ruote-kit is somewhat intertwined with the little
> changes we made to ruote itself. Plus some remarks and notes about our
> concerns. Again, we can provide code, extra hands and further
> discussion about each and every topic below. Some of them are part of
> a work in progress.
Hi Nando,
first thanks for all this feedback, it's invaluable.
> * JRuby-friendly.
> With some minor tweaking, ruote-rest works well with JRuby 1.2. We
> have to make sure that ruote/ruote-kit are 100% JRuby-compatible.
I would be very interested to know about those minor tweaks.
> * Our front-end guys are working on a swing-based heavy client which
> relies on a clean, stateless REST interface to ruote-rest. Will ruote-
> kit be stateless as well?
Kenneth is the father of ruote-kit. I hope he will adopt the same
"interface" for ruote-kit, but in the end, he's in charge. If there
are changes and evolutions and will make sure to port them back to
ruote-web2 which I continue to develop (and hopefully maintain).
For now, the only change we envision is relying on more explicit RELs
in links so that it's easier for clients to find their way among the
interface.
The statelessness, is IMHO, essential and should be preserved at all
cost (else we should stop labelling ourselves "rest"[ful]).
> * Centralized process-definition:
> We have created a new URI
> ---begin snip----
> GET /startables
In ruote-web2, there is the "definitions" resource. I don't know what
Kenneth will want to do with ruote-kit. Ruote-rest had no such
concept, as the idea was/is "engine-only". I was trying to leave such
"content management" concerns to other softwares (any other [static]
web server).
> * Comet support: it would be nice that REST clients were notified of
> any changes in their workitems. We know the implementation is server-
> dependent (Glassfish:Grizzly/Jetty/Ebb/Rails:Juggernaut,...), but
> Jetty and Glassfish are in our roadmap. A more ruby-esque approach
> could be implemented in ruote-kit as well?
I would prefer keeping comet stuff out of ruote-rest / ruote-kit, I
understand your requirement, but I don't think this is "core" to ruote
and ruote-{rest|kit|web2}.
> * Maven/Rake: we noticed that ruote is migrating to Maven. Any plans
> for route-kit?
Sorry, ruote is not migrating to maven. The pom.xml that you see is
used when packaging ruote as a jar for the maven world (I use ruote on
top of JRuby for my day job).
> * As for the tracker/poject mgmt tool, why Lighthouse?
Sorry, we're not using Lighthouse.
the trackers are at http://rubyforge.org/projects/openwferu
> * Oracle support. We can help here as well.
We're using ActiveRecord (and DataMapper lately), Oracle support is
thus indirect.
> Hope this makes sense. I'll be expanding this thread as I discuss the
> subjet with more co-workers.
Thanks for sharing, kind regards,
--
John Mettraux - http://jmettraux.wordpress.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
