Present: Aleix, Piotr, Raul, Stian (part), Graham
What I have done: I've worked on ROSR 6 API: http://www.wf4ever-project.org/wiki/display/docs/RO+SRS+interface+6+-+discussion
- I don't have a clear vision of handling external resources. How should they be represented in the API and what format should they have?
- I don't have a clear vision of annotations as API resources but I haven't had much time to think about it yet.
- I have yet to learn what are link relations in context of this API
learn about the link relations, look for other projects/APIs that distinguish internal and external resources
worked on the API documentation. Now I've got a first draft of the API with a bit of information on each point of the template (except for link relations) ready for be reviewd.
Not sure on where to focus. Look for more information about security or cache in rest services, work on an example client, add rdf to the service, uri template expansion, etc.
None, but would like to see the APIs of the others to see if there's something I'm missing. And also got a bit confussed yesterday about the technical-philosophical discussion: Am I really doing REST??
Stability Evaluation API:http://www.wf4ever-project.org/wiki/display/docs/Stability+Evaluation+API
Yesterday and today i am working on roevo
Workflow executor (showcase 0). Using pretty much same API as the Transformation Service.
The same. No time for the Transformation service doc today
None, but an idea.
I've been thinking about the job API of the Transformation Service (http://www.wf4ever-project.org/wiki/display/docs/Wf-RO+transformation+service ) and my new Workflow Runner - I would want to have a common pattern of POST --> PUT so that the job does not actually start before you PUT the status on that particular job. POST is not idempotent - so if a POST request to make a job fails, the client would not know if the job is running or not.
However, if the actual job does not start before you PUT something later, you can just PUT the "run" status several times on failure (as PUT is idempotent).
However I am uncertain if I should do this as POST with an empty-ish body, which mints and returns a UUID-based URI, which can then be PUT to, or a POST with the inital data, which then is modified with PUT to make it running, or finally a separate status resource which is PUT to make it running.
(More discussion of this later - see below)
- complete checklist API document, upload to wiki. http://www.wf4ever-project.org/wiki/display/docs/RO+checklist+evaluation+API
- created simple script to convert textile markup to wiki format.
- other stuff - RO manager installation notes/test for Kristina.
- API review?
- Help Kristina with RO manager install
- API to review
- anyone to review mine?
- early finish today
- Read about what is a REST interface, update accordingly the recommender service interface
- Update the API documentation to reflect those changes and to be described using the proposed template
(Rafa has since had to attend to other matters, and will probably not be able to participate further in the sprint this week.)
There was some general uncertainty about what is REST, and about link relations. No time to discuss in stand-up, but need to pick up ASAP, and as we do early draft API reviews.
See also: http://www.wf4ever-project.org/wiki/download/attachments/3506665/REST-APIs.pdf
(maybe I should update with note about link relations?)
Confirmed 2-week sprint duration
Stand-up chat log
And an on-time submission from rafa: