John,

Thanks for responding.


> From: John Mettraux <[EMAIL PROTECTED]>
> Reply-To: <[email protected]>
> Date: Thu, 31 Jan 2008 07:48:47 +0900
> To: <[email protected]>
> Subject: [openwferu-dev] Re: Listing processes
> 
> 
> Hi,
> 
> 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?

> 
> 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.
> 
>> 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).

But that's fine.
> 
>> Technically start and stop ought to be POST and DELETE too.
> 
> start process, stop process... launch process is a POST, cancel
> process a DELETE, why not.
> start engine, a POST on /engines, stop engine, if it's a DELETE, it
> implies that the engine cannot get restarted...

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?

> 
>> 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.

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.

V/R,

Pat.



--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to