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

[David Raznick]

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

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