So let me try to summarize: GET /engine returns TBD at this point (Generic engine info maybe. Status? Load info? Not implemented yet, right?)
POST /engine starts the engine DELETE /engine deletes engine We limit to one engine and would return an error for a second POST /engine PUT /engine?cmd=halt halts the engine PUT /engine?cmd=resume resumes the engine Note: I would not document updating a resource with a POST (reserved to create a resource) although implementation will probably allow it. Did you imply that a PUT /engine?cmd=start|stop would also work? And be different from a POST? We may not need the POST/DELETE in the one engine scenario. This would be fine too. [I will check on the scheduled process name but it seems like it is the right name] Thanks, Pat. > From: John Mettraux <[EMAIL PROTECTED]> > Reply-To: <[email protected]> > Date: Thu, 31 Jan 2008 09:30:38 +0900 > To: <[email protected]> > Subject: [openwferu-dev] Re: Listing processes > > > 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 -~----------~----~----~----~------~----~------~--~---
