On Tue, Apr 7, 2009 at 2:05 AM, John Mettraux <[email protected]> wrote:
> > 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. Hi Nando, Mario & John Thanks for the feedback. I told John just now in #ruote that I read the mails last night several times, taking notes and digesting it all. Great job! > * 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. > I would ultimately rely on cruisecontrol.rb to test route-kit and ruote on several different interpreters, but making it run on any Ruby platform (within reason) is definitely key for me to make the reach of the project so much more. > > * 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]). > Agree with John over here. Our discussions for ruote-kit is to be pretty much to keep ruote-rest's interfaces with a lot of improvements around the usage of REL values. It's the assembly of the project/code/environment itself that is gonna be dramatically different, not so much the interfaces. I'm very happy with ruote-rest from a REST client point of view, and would keep it that way. > > * 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). I'm gonna agree with John on this one, but the planned architecture for ruote-kit would allow you to do this without ruote-kit supporting it... Let my try and keep this small. I've updated my "ramblings" gist to reflect the following: http://gist.github.com/74844 * Custom resources can be defined by the specific installation * 'public' folder for uploaded process definitions, or anything that would matter to the implementors With custom resources I mean you can hook into routing used by ruote-kit (via rack-mount) to expose your own resources easily. You'll also gain full access to the engine as well, and all the other niceities. At this stage I'm making a mental note of supporting plugins, possibly, but that would be *low* priority. > > * 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}. I agree with John 100% here, but the layout/implementation of ruote-kit should be so that you could implement this as a custom resource/participant/plugin and not worry about it conflicting with anything else in ruote-kit. People will definitely have needs similar to this in the future, possibly for things we can't imagine yet, and that is why I've taken on ruote-kit and made this kinda flexibility number 1 priority. > > * As for the tracker/poject mgmt tool, why Lighthouse? > > > Sorry, we're not using Lighthouse. > > the trackers are at http://rubyforge.org/projects/openwferu John, in my ramblings gist I've mentioned Lighthouse. Personally I'm not fond of the Rubyforge trackers, and Lighthouse works quite well (especially from a github POV). But I'm open for suggestions, and for the record a recent tweet from @defunct suggested that github would get it's own basic bug tracker in the near future. The biggest issue with Rubyforge is that from South Africa it's nearly impossible to login and I have to send my Rubyforge traffic through Tor (it something to do with our two major ISP's caches). > > Hope this makes sense. I'll be expanding this thread as I discuss the > > subjet with more co-workers. > > Thanks for sharing, kind regards, Indeed, it's very insightful to hear how others are using the project, and it's comforting to know that while I've just been busy making notes and drawing out plans on paper, I'm on target. Looking forward to getting you guys involved as the code starts to take shape. Best -- Kenneth Kalmer [email protected] http://opensourcery.co.za --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
