On Jan 31, 2008 9:16 AM, Pat Cappelaere <[EMAIL PROTECTED]> wrote: > > From: John Mettraux <[EMAIL PROTECTED]> > > > > On Jan 30, 2008 10:55 PM, Pat Cappelaere <[EMAIL PROTECTED]> wrote: > >> > >> I am trying to document a potential call to get the Engine Status > >> Like in: > >> > >> GET /wfcs/engine > >> > >> I would probably expect to get the engine status (running, paused...) and > >> a list of running/scheduled processes. Anything else? > > > > Shouldn't the list of running/scheduled processes belong to > > > > GET /processes > > True. > So question now is what does Get /engine returns? Engine status only?
Generic engine info maybe. Load info. > > It's how it's currently implemented in Kisha. > Agree. > > > > >> So I can now find the jobs on the schedule, I can get the job_id and the > >> job > >> object. I can get the schedule_info on that object. > >> > >> How do I get the wfid short of parsing the ascii string that could be in > >> the > >> job_id (could also be a counter, I guess)? I am not seeing any convenience > >> functions. I can always write one :) > > > > IIRC, the process waiting to get scheduled has still no wfid, it'll > > get one at the moment it is launched. > > Hummmm! I do see a kotoba name in there. Isn't it the wfid of the "scheduling process" itself ? > >> The other thing is that I am not too pleased in the WfXML document is about > >> the halt/resume cmds to the engine. REST would suggest a PUT like: > >> PUT /wfcs/engine > >> <entry... > >> <cmd>halt|resume</cmd> > >> </entry> > >> > >> Wondering if it would be acceptable to deviate and use something like: > >> > >> GET /wfcs/engine?status=halt | pause | start | stop > >> > >> Or even > >> GET /wfcs/engine/halt > >> > >> WDYT? > > > > GET shouldn't modify anything. > Agree on that in general but was thinking to make an exception in that case. > Alternative is to do a PUT but it seemed so much more cumbersome to do > (especially in the browser). The usual alternative I've seen is POST /blah?_method=PUT See for example : http://www.oreillynet.com/pub/a/ruby/2008/01/14/shoes-meets-merb-interfacing-a-gtk2-front-end-and-a-rails-web-service.html?page=1 I have integrated this _method trick in my rufus-verbs lib as well : http://rufus.rubyforge.org/rufus-verbs/ > POST on /engines creates the engine resource, so it would start it. > DELETE /engines would delete the resource, therefore stopping it. > To restart, re-do a POST, right? Yes, from a blank slate. > >> And can we assume one engine resource only? > > > > In which context ? In your document, you seem to be assuming one > > [RESTful] host and potentially multiple engines. > > Well! You convinced me to keep it to one engine, right? I agree that it > would be confusing to have several engines running. I have the feeling that "the engine" is something easy to grasp, a reference point. I'm no expert at all, but "scaling" scenarii with more than one engine would benefit from not having to deal with "URL rewriting", just host choosing... (difficult to choose my words here, I have to stop). So one engine feels easier. > So if you do a POST /engines and engine exists and is running, it would be > ignored or would return the current engine or an error. > > I would have to capture that in documentation somehow if you agree. OK, best regards, -- John Mettraux -///- http://jmettraux.openwfe.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OpenWFEru dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/openwferu-dev?hl=en -~----------~----~----~----~------~----~------~--~---
