[ckan-dev] Specification of data processing web services.

Thu Jun 14 14:55:08 UTC 2012

On 14 June 2012 15:44, David Raznick <kindly at gmail.com> wrote:

> >
> > I don't like this as task_id may not be unique what is the point of this
> > maybe setting a user reference may meet the same need
>
> If the task_id sent is not unique then the service can throw an error.
>
> Maybe, as you said, there is a need for two ids one for the service an
> one given from the sender but that seems to complicate things
> unnecessarily as there needs to be some way to reference the task and
> I am not too happy about there being two references.
>
> Any sensible automated user of the tasks should send through a uuid
> anyway or leave it upto the service to generate one.
>

Any sensible automated task would *never* send a uuid as, as you say the
service could throw an error so why risk it?

> >>
> >>
> >> /task
> >> Start a new task. (this should generate a uuid for long running tasks)
> >
> > should the uuid not be universal even if just thrown away by the service?
>
> yes it would be universal.
>
> >>
> >>
> >> api_key (optional):  api key needed to post the results to the
> >> result_url. eg. frewoitryu398wtrhw
> >>
> > this seems to limiting do we want something more like
> > send_result {
> > method: POST
> > url : .....
> > params : {api_key:....., something_else:...}
> > http_headers : [{'X-API-KEY':'...'},..]
> > }
>
> Thats a very good point as this is very ckan specific at the moment
> but I am wary of the complication.  The results consumer could have
> pretty strict rules as to what it needs to accept and for the moment
> that is what ckan accepts.
>
>
> > what about authentication and stuff like that?
>
> It is up to the service.   Any long running task should make sure it
> can't be abused.
>
> We may need to build some api calls to basically do a check access in
> ckan.  For the datastorer example the service this should be enough to
> decide if you can run the task.  At the start I was just going to
> allow sysadmins to use it (I think there is an api call for that).
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20120614/8e139dd6/attachment-0001.html>