chung wrote:
> Hi All,
>
> On Thu, 2010-06-24 at 22:59 +0300, Luchesar V. ILIEV wrote:
>   
>> Hi,
>>
>> Not a comment per se, but closely related to the question about
>> specifying the policies. I'm trying to compile an "OpenTox AA best
>> practices and implementation guide"; the title might eventually
>> change, but the general idea is to have a singe, likely only internal
>> document, documenting the AA implementation in as much detail as
>> necessary for the developers -- in order to achieve perfect
>> synchronization between the different development teams.
>>
>> One thing that's obviously going to be in this document is exactly
>> what you ask: how the policies are specified when a client/user is
>> creating new resource. I suppose we won't require the client/user to
>> create a complete OpenSSO policy, so we could use much simpler syntax.
>>     
>
>   I agree that clients should not take on the creation of complex XML
> documents for creating a resource with some policy. Instead, if we need
> to keep it simple, we can specify a list of optional policies from which
> the client can choose and maybe provide some advanced options also. Then
> the client can POST parameters either in the Header or using forms
> choosing from a list of standard policies (like policy=1) [This is quite
> similar to how Creative Commons licenses work]
>
>   
If I remember right, we have already discussed something similar, even
having a service with predefined policies , from which one could select.

Regards,
Nina
> Regards,
> Pantelis
>
>   
>> However, the exact syntax might depend on where we'll put that
>> information... Do the HTTP headers make sense as such place?
>>
>> Cheers,
>> Luchesar
>>
>>
>> On Thu, Jun 24, 2010 at 19:16, chung <chvng at mail.ntua.gr> wrote:
>>     
>>> Heloooo,
>>>  Any comments?
>>>
>>> On Mon, 2010-06-21 at 18:33 +0300, chung wrote:
>>>       
>>>> Dear All,
>>>>   NTUA web services ( http://opentox.ntua.gr:3000 ) now support some
>>>> initial functionalities of the A&A API. All resources are accessible to
>>>> all users in the groups partner and development. You can either provide
>>>> a token in the url (url endcoded) or your credentials in the URL. The
>>>> latter is more convenient but less secure. For example, if you want a
>>>> list of all models, use the URL: /model/?username=...&password=...
>>>>   All connections between the services and the openSSO server are over
>>>> SSL.
>>>>
>>>> One question:
>>>> * Does the client specify some parameters about the policy of the
>>>> created resource (e.g. model)? We have to specify which.
>>>>         
>>> What about this?
>>>       
>>>> We also have to discuss about the QPRF reporting services (see
>>>> http://opentox.org/dev/apis/api-1.2/report ). An initial implementation
>>>> of the QPRF editor is available at
>>>> http://opentox.ntua.gr/Q-edit/launch.html (source code at
>>>> http://github.com/alphaville/Q-edit ).
>>>>
>>>> Regards,
>>>> Pantelis
>>>>
>>>> _______________________________________________
>>>> Development mailing list
>>>> Development at opentox.org
>>>> http://www.opentox.org/mailman/listinfo/development
>>>>
>>>>         
>>> _______________________________________________
>>> Development mailing list
>>> Development at opentox.org
>>> http://www.opentox.org/mailman/listinfo/development
>>>
>>>       
>> _______________________________________________
>> Development mailing list
>> Development at opentox.org
>> http://www.opentox.org/mailman/listinfo/development
>>     
>
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>