Hello Tobias, Christoph, All,

We have been also discussing the issue here, but without conclusions. 
The case when a service (e.g. descriptor calculation) just process the
data and generates a result to be stored elsewhere is a typical RPC
behaviour, typical for  SOAP WS and is more or less a common use case
for OpenTox.  It is not clear for me how to map it best to the REST
style, if possible at all.

Best regards,
Nina


Christoph Helma wrote:
> Excerpts from Tobias Girschick's message of Wed Oct 07 16:00:26 +0200 2009:
>   
>> Hello All,
>>
>> there is another point that arose during our internal discussions on the
>> API. Where does a service that wants to store data, e.g. calculated
>> data, know where (or on which server) to store (POST) it? Can we
>> introduce something like server_uri as additional parameter for the
>> services?
>>
>> A possible scenario is that the user calculates features
>> using  /algorithm/descriptorcalculator and wants to ensure that the
>> generated features (and feature_definitions) are POSTed to a specific
>> server, say 
>> POST feature123 http://userserver:8080/feature 
>> POST feature_definition345 http://userserver:8080/feature_definition
>>
>> This issue will/might also arise if a developer does not want to
>> implement the whole (or most of) the API, but just a new model
>> development or descriptor calculation service as a contribution to
>> OpenTox.
>>     
>
> Do you think that choosing a dataset server e.g. from a configuration
> file is too unflexible for your algorithm service? Your proposal would
> mean that each user can select a different dataset server - is this a
> common use case? I personally would not offer this choice to my users,
> but I think that every developer has the freedom to add parameters to
> the existing API (as long as they are documented and the offical API
> works with a reasonable default). 
>
> Regards,
> Christoph
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>