[SAGA-RG] Service Discovery spec updated at last ...

[Sylvain Reynaud]

Steve Fisher a écrit :
> As I seem to be in a minority of one wanting to call the access to the
> file package a file service rather than a directory service I guess I
> have to back down - but also bear in mind that LDAP or M'Softs active
> directory are considered to be directory services - whereas I presume
> that the SAGA directory service is a directory of files??
>   
There is no explicit SAGA file/directory service; a file object manages 
a single file, and a dir object manages a single directory.
But dir also enables creating new file objects (method open) and new 
directory objects (method openDir) on the same server, that's why I 
think that dir is the closest to a file service...

Sylvain
> Steve
>
> 2008/12/17 Andre Merzky <andremerzky at gmail.com>:
>   
>> Quoting [Steve Fisher] (Dec 17 2008):
>>     
>>> 2008/12/17 Sylvain Reynaud <Sylvain.Reynaud at in2p3.fr>:
>>>       
>>>> Hi Steve and Andre,
>>>>
>>>> I am the reviewer who criticised having different "service type names" for
>>>> file and for directory (and also for logical file/logical directory).
>>>>
>>>> I agree with Andre's suggestion of limiting this to dir (and also to logical
>>>> dir I guess ?), because users use discovery services to discover the base
>>>> directory they can access, while they use logical file catalogs to find
>>>> files. Moreover, dir can be seen as a kind of implicit service with its
>>>> open() and openDir() methods.
>>>>
>>>> Regards,
>>>> Sylvain
>>>>         
>>> Yes but I think it is more fundamentally a file service - the
>>> directory is just one way of organising a bunch of files. The package
>>> is also the file package rather than the directory package.
>>>       
>> Sure, valid point of view, I agree.
>>
>> But naming it 'dir' makes clear that the returned URL's are
>> usable to create a saga::file::directory instance - and that
>> is what this table is about, I though.
>>
>> Best, Andre.
>>
>>
>>
>>     
>>> Steve
>>>
>>>       
>>>> Andre Merzky a écrit :
>>>>         
>>>>> [...]
>>>>>           
>>>>>> I don't agree with this - it used to be your way round and it was
>>>>>> criticised by one of our reviewers. You don't generally want to access
>>>>>> directories and files by different services unless the underlying
>>>>>> system used a  universal naming schema such as AFS.   However,
>>>>>> checking the main spec again, I see you have no way of controlling
>>>>>> which file/directory service you use - it is under the control of the
>>>>>> implementation.
>>>>>>
>>>>>>             
>>>>> Well, the service is (explicitely or implicitely) specified
>>>>> by the URL you use to open the file/dir instance, like
>>>>> 'ftp://ftp.redhat.com/' points to a very specific ftp
>>>>> server/service.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> So at least file, directory, logical-file and
>>>>>> logical-directory should be removed from this table until
>>>>>> such time as they provide a means of selecting the service
>>>>>> to use.
>>>>>>
>>>>>>             
>>>>> Would it be ok for you if we remove 'file' then, and limit
>>>>> to 'dir'?  Usually, one would like to discover services for
>>>>> whole file systems, not for individual files, I presume?
>>>>>
>>>>> [...]
>>>>>           
>>>>         
>>
>> --
>> Nothing is ever easy.
>>
>>