2008/12/16 Andre Merzky <andre@merzky.net>:

Hi Steve,

sorry again for the late reply! Anyway, I attach a pdf with some suggested changes marked, all minor IMHO (red: removed text, blue: changed text, green: added text, diff style in verbose sections).

Please let me know if you want these changes commited, or if I possibly misunderstood parts (again). Otherwise, I think its really ready to go out!

Summary of changes:

- some formatting (found ^M's which messed things up, some spacing, page break, etc)

Thanks - that is probably using a mixture of eclipse and emacs on windows ...

- added a number of exceptions, refering their syntax to the core spec (e.g. TimeOut, etc)

OK

- removed some exeptions, too, as error conditions could never occur, I think.

You have removed "NoSuccess" from the service_description calls. I thought this was a catch-all which should almost always be present? You have added a note that the returned list can be empty - but you have it as "reurned"

- fixed some inconsistencies (service naming for SAGA services was different in attribs and verbose text, for example)

- chaged casing for MUST, SHOULD, etc (was often lowercase where it should have been uppercase, IMHO)

I don't object to the style

- separated suggested SAGA service names for files and directories (a file URL cannot be used for a dir, and vice versa)

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. 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. Just above this you have added some text with the word "Services" - it should be "services" A few lines later you have changed related service to the plural - please change it back. Only one value is permitted. As a note on the discoverer constructor you have added "if the URL" - to be consistent it should read "if the url" Has "IncorrectURLException" now become "IncorrectURL"?

- added a 'Implementation MAY use saga context attrib names for auth filtering', to clarify that this is not required (auth filter generation may imply otherwise).

I see you have rejected 3 of our constructors in favour of 1 with 2 optional arguments. I presume the language binding is allowed to do it in a way that is natural for that language. You suggest that specifying a url as an empty string should be equivalent to omitting it. This offends me - and I think it is wrong in other places in the SAGA spec. So I would like to see something like: CONSTRUCTOR (in session session, in url url, out discoverer dis) and state that both parameters are optional in the notes. In a similar manner I don't like having the list_services call repeated (with and without the optional parameter) as it just makes the specification less readable. Perhaps we can agree on these points of representation before checking anything in. I would like to see 1 constructor with 2 optional arguments (as you have it) - but no default empty string and to leave the list_services as one call with an optional argument. It might be worth a phone call - where are you? Steve

Many thanks,

Andre.

Quoting [Steve Fisher] (Dec 05 2008):

...

Date: Fri, 5 Dec 2008 17:59:12 +0000 From: "Steve Fisher" <dr.s.m.fisher@gmail.com> To: saga-rg@ogf.org Subject: [SAGA-RG] Fwd: Service Discovery spec updated at last ...

Hi,

Unfortunately I have not had any reaction to this. I don't like to assume that silence means that everybody is happy. Perhaps at least a co-chair could look through and give me the go-ahead to resubmit.

Implementation work is due to restart in C++ on Monday and start in Java on the same date.

Steve

---------- Forwarded message ---------- From: Steve Fisher <dr.s.m.fisher@gmail.com> Date: 2008/12/1 Subject: Service Discovery spec updated at last ... To: saga-rg@ogf.org

Hi,

I have finally got the spec updated - please see attached .dvi and .pdf files. Please make any final comments before it goes back to the OGF editors. Work on implementation will resume next week.

Steve -- Nothing is ever easy.

2008/12/17 Andre Merzky <andre@merzky.net>:

Hi Steve,

Quoting [Steve Fisher] (Dec 16 2008):

...

...

- removed some exeptions, too, as error conditions could never occur, I think.

You have removed "NoSuccess" from the service_description calls. I thought this was a catch-all which should almost always be present?

You (implicitely) write that the implementation MUST fill the URL attribute, so it MUST be available, and a get_attribute(url) MUST succeed. Now, get_url is just a shortcut to get_attribute("url"), so it cannot fail, can it?

OTOH, if you consider that to be fallible (is that English? ;-), e.g. because the backend cannot guarantee state or whatever, then you probably need to add all possible exceptions listed for get_attribute from the attributes interface, not only NoSuccess?

Or, alternatively, you specify that get_url() maps all possible get_attribute() exceptions to NoSuccess - then that needs to be added again of course. But then again, why not pass them through?

At it was, it was not clear why that exception was there, and others like TimeOut was not. Your call :-)

I see your point - however this implies that a list_services call must always return "complete" services such that get_url() will succeed. I think this is reasonable so I accept your suggestion

...

You have added a note that the returned list can be empty - but you have it as "reurned"

Thanks.

...

...

- separated suggested SAGA service names for files and directories (a file URL cannot be used for a dir, and vice versa)

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.

Your example clarifies this - thanks

...

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?

Yes I think what you want to discover is a file service - and that this file service will offer both file and directory operations. I guess the same is true for the logical file service. If this is the case the table was fine as I had it!

...

Just above this you have added some text with the word "Services" - it should be "services"

Thanks.

...

A few lines later you have changed related service to the plural - please change it back. Only one value is permitted.

I am confused: we are talking about:

"_related_services_ the uids of a services related to the one being looked for"

? Related Services are explicitely listed in plural everywhere else in the document:

- figure 1 shows a n:n relation - the related_services attribute is a vector attrib, and the description talks about a list of uid's - get_related_services returns a list of related services, too.

So why is it a single value during query?

because you say "related_service = 'fred'" or "related_service in ('fred', 'bill')" where it will always be used naturally in the singular. This assumes that 'fred' and 'bill' are actually service uids.

...

...

- added a 'Implementation MAY use saga context attrib names for auth filtering', to clarify that this is not required (auth filter generation may imply otherwise).

I see you have rejected 3 of our constructors in favour of 1 with 2 optional arguments. I presume the language binding is allowed to do it in a way that is natural for that language. You suggest that specifying a url as an empty string should be equivalent to omitting it. This offends me - and I think it is wrong in other places in the SAGA spec.

Then we should have changed it in the SAGA spec possibly - but we did not. I think we should keep that consistent for the extensions, too.

...

So I would like to see something like:

CONSTRUCTOR (in session session, in url url, out discoverer dis)

and state that both parameters are optional in the notes.

What is a difference between an empty URL and an optional one? I don't think I can think of any case where an empty URL would have a different meaning (like you motivated for the empty authz filter versus no authz filter).

Again, I would be happy we could keep that consistent over the API and extensions.

I would like to be consistent - however the url here is not a string but a SAGA URL object - so it cannot have a default value of "". Whatever syntax is appropriate for an optional session parameter is also good for an optional url parameter. In a python API I would then expect to see named parameters with defaults of None and in Java I would expect the constructor to accept actual parameters of null objects.

...

In a similar manner I don't like having the list_services call repeated (with and without the optional parameter) as it just makes the specification less readable.

Yes, but (a) you have it listed twice in the prototype section, and (b) that is again consistent with what we did elsewhere. I seem to remember that we argued about it before? Sorry if so...

We did - and I think I followed what we agreed to do - two entries in the initial summary and then one in the expanded description to avoid excessive duplication and increase readability.

...

Perhaps we can agree on these points of representation before checking anything in. I would like to see 1 constructor with 2 optional arguments (as you have it) - but no default empty string and to leave the list_services as one call with an optional argument.

To clarify that again: arguments with a default value are optional arguments, e.g. they can be left out when calling the function. In your list_services() method, you want to have an explicit distinction between the two signatures, i.e. you do _not_ want to have a default argument for the authz filter - that is why you have two prototypes. I agree that this is the right way to do it.

For the constructor, I don't see that yet, i.e. I don't see the value of having an additional c'tor without URL, versus having the URL default to an empty string, as we have everywhere else in the spec.

Could you please clarify the semantic difference between the two?

As mentioned above the url is a saga object and so cannot be an empty string as that is a a different type.

As for the session, that is always optional, as described in 3.5.2 in the Core spec - no need to list additional constructors for that either.

...

It might be worth a phone call - where are you?

In Germany, so roughly the same time zone. :-) Tomorrow would work, I'll send you my number in a separate mail.

OK - it may not be necessary. However I would like to get this spec out of the way. Steve

forgot the attachement... *blush* Andre. Quoting [Andre Merzky] (Dec 17 2008):

Date: Wed, 17 Dec 2008 22:44:42 +0100 From: Andre Merzky <andre@merzky.net> To: Steve Fisher <dr.s.m.fisher@gmail.com> Cc: Andre Merzky <andre@merzky.net>, saga-rg@ogf.org Subject: Re: Service Discovery spec updated at last ...

Quoting [Steve Fisher] (Dec 17 2008):

...

...

...

...

- separated suggested SAGA service names for files and directories (a file URL cannot be used for a dir, and vice versa)

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.

Your example clarifies this - thanks

...

...

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?

Yes I think what you want to discover is a file service - and that this file service will offer both file and directory operations.

Yes.

...

I guess the same is true for the logical file service. If this is the case the table was fine as I had it!

Yes, from service perspective it was, I agree.

The problem is that the end user simply has no means to know what to do with the returned Service URLs: are they usable to create a directory instance _or_ are they usable to cerate a file instance? It can't be both, and, apart from guessing or trying, the user has no good means to distingish these cases.

That is why I suggested to query for the two types individually, but, taking you arguments, and Sylvain's, I think its ok to limit ourself to directories (I assume that would usually be the root directory served by the service).

See new version attached. Sorry if I am repetetive, just trying to be clear...

...

...

...

A few lines later you have changed related service to the plural - please change it back. Only one value is permitted.

I am confused: we are talking about:

"_related_services_ the uids of a services related to the one being looked for"

? Related Services are explicitely listed in plural everywhere else in the document:

- figure 1 shows a n:n relation - the related_services attribute is a vector attrib, and the description talks about a list of uid's - get_related_services returns a list of related services, too.

So why is it a single value during query?

because you say "related_service = 'fred'" or "related_service in ('fred', 'bill')" where it will always be used naturally in the singular. This assumes that 'fred' and 'bill' are actually service uids.

Thanks, got it.

...

...

What is a difference between an empty URL and an optional one? I don't think I can think of any case where an empty URL would have a different meaning (like you motivated for the empty authz filter versus no authz filter).

Again, I would be happy we could keep that consistent over the API and extensions.

I would like to be consistent - however the url here is not a string but a SAGA URL object - so it cannot have a default value of "".

Basically, it means that the URL would be created by giving an empty string to the URL's constructor.

Thus

object (saga::url u = "");

is a short form for

object (saga::url u = saga::url (""));

...

Whatever syntax is appropriate for an optional session parameter is also good for an optional url parameter.

Well, we describe the session parameter default explicitely in section 3.5.2 in the Core spec, but we do not describe it for other parameter types anywhere, in particular not for URL.

...

In a python API I would then expect to see named parameters with defaults of None and in Java I would expect the constructor to accept actual parameters of null objects.

Sure sure, but that is a language binding issue. You see the same for the current Python bindings for the core classes IIRC.

Again, I think you are not adding any new semantics by the second constructor...

...

...

...

In a similar manner I don't like having the list_services call repeated (with and without the optional parameter) as it just makes the specification less readable.

Yes, but (a) you have it listed twice in the prototype section, and (b) that is again consistent with what we did elsewhere. I seem to remember that we argued about it before? Sorry if so...

We did - and I think I followed what we agreed to do - two entries in the initial summary and then one in the expanded description to avoid excessive duplication and increase readability.

I removed it again.

...

...

For the constructor, I don't see that yet, i.e. I don't see the value of having an additional c'tor without URL, versus having the URL default to an empty string, as we have everywhere else in the spec.

Could you please clarify the semantic difference between the two?

As mentioned above the url is a saga object and so cannot be an empty string as that is a a different type.

See above, that is no problem.

...

...

As for the session, that is always optional, as described in 3.5.2 in the Core spec - no need to list additional constructors for that either.

...

It might be worth a phone call - where are you?

In Germany, so roughly the same time zone. :-) Tomorrow would work, I'll send you my number in a separate mail.

OK - it may not be necessary. However I would like to get this spec out of the way.

Me too :-)

In the attached version, I tried to address the things we agreed upon, and changed the service types/names table as proposed. Could you give it another pass, please? I left the Constructors untouched for now, until we agreed on something, ok?

Also, there is a question from me at the bottom of page 5:

"Note: Why not TimeOut, AuthorizationFailed, etc??"

Do you have a opinion here?

Thanks, Andre.

...

Steve -- Nothing is ever easy.

Quoting [Steve Fisher] (Dec 18 2008):

...

...

I would like to be consistent - however the url here is not a string but a SAGA URL object - so it cannot have a default value of "".

Basically, it means that the URL would be created by giving an empty string to the URL's constructor.

Thus

object (saga::url u = "");

is a short form for

object (saga::url u = saga::url (""));

...

Whatever syntax is appropriate for an optional session parameter is also good for an optional url parameter.

Well, we describe the session parameter default explicitely in section 3.5.2 in the Core spec, but we do not describe it for other parameter types anywhere, in particular not for URL.

This discoverer class should have has the same constructor as the job_service. Where the spec says:

Exactly!

CONSTRUCTOR (in session s, in url rm = "", out job_service obj);

However the Java interface has got 3 "constructors" in the job factory with arguments:

(session, url) (session) ()

I want the Java API to be like this but, for convenience, with the addition of:

(url)

Sure, but that is a language binding issue. And again, that probably should follow the language binding for the job_service, although I do not know how that is rendered in Java at the moment.

I am happy to express this in the spec with a single constructor with 2 optional arguments - so our *only* concern is the precise notation. I don't want to rely upon people having read section 3.5.2 of the main spec to appreciate that session parameters are always optional and I don't like a notation which implies using a url from the default constructor being used to represent a default url.

I added an explicit reference to section 3.5.2 and 2.2.2 of the core spec, where the handling of session, and of other default parameters, is descibed in some detailed. 2.2.2 says that default parameters are to expressed in the language bindings in a way native to the languge, and should give you enough freedom for Java. With that, is the notation precise enough for you? Best, Andre. ------------------------------------------ - CONSTRUCTOR Purpose: create a new discoverer object Format: CONSTRUCTOR (in session session, ! in url url = "", out discoverer dis); Inputs: session: session handle url: URL to guide the implementation Outputs: dis: new discoverer object Throws: NotImplemented IncorrectURL + DoesNotExist + AuthorizationFailed + AuthenticationFailed + TimeOut NoSuccess Notes: - the url specified as in input parameter is to assist the implementation to locate the underlying information system such that it can be queried. + - if the url is syntactically valid, but no + backend service can be contacted at that URL, + a 'DoesNotExist' exception is thrown. + - the semantics for the other exceptions is as + outlined in the SAGA Core API specification. + - note that the session parameter is optional, + as described in the SAGA Core API + specification, section 3.5.2. Also Section + 2.2.2 of the same document applies to + url and its default value. ------------------------------------------ -- Nothing is ever easy.

Quoting [Steve Fisher] (Dec 18 2008):

OK I can buy that. I should have complained about the notation when the core spec was being put together.

Yes :-)

If you reference it that should be fine.

Ok, cool - one down :-) Cheers, Andre.

Steve

2008/12/18 Andre Merzky <andre@merzky.net>:

...

Quoting [Steve Fisher] (Dec 18 2008):

...

...

...

I would like to be consistent - however the url here is not a string but a SAGA URL object - so it cannot have a default value of "".

Basically, it means that the URL would be created by giving an empty string to the URL's constructor.

Thus

object (saga::url u = "");

is a short form for

object (saga::url u = saga::url (""));

...

Whatever syntax is appropriate for an optional session parameter is also good for an optional url parameter.

Well, we describe the session parameter default explicitely in section 3.5.2 in the Core spec, but we do not describe it for other parameter types anywhere, in particular not for URL.

This discoverer class should have has the same constructor as the job_service. Where the spec says:

Exactly!

...

CONSTRUCTOR (in session s, in url rm = "", out job_service obj);

However the Java interface has got 3 "constructors" in the job factory with arguments:

(session, url) (session) ()

I want the Java API to be like this but, for convenience, with the addition of:

(url)

Sure, but that is a language binding issue. And again, that probably should follow the language binding for the job_service, although I do not know how that is rendered in Java at the moment.

...

I am happy to express this in the spec with a single constructor with 2 optional arguments - so our *only* concern is the precise notation. I don't want to rely upon people having read section 3.5.2 of the main spec to appreciate that session parameters are always optional and I don't like a notation which implies using a url from the default constructor being used to represent a default url.

I added an explicit reference to section 3.5.2 and 2.2.2 of the core spec, where the handling of session, and of other default parameters, is descibed in some detailed.

2.2.2 says that default parameters are to expressed in the language bindings in a way native to the languge, and should give you enough freedom for Java.

With that, is the notation precise enough for you?

Best, Andre.

------------------------------------------ - CONSTRUCTOR Purpose: create a new discoverer object Format: CONSTRUCTOR (in session session, ! in url url = "", out discoverer dis); Inputs: session: session handle url: URL to guide the implementation Outputs: dis: new discoverer object Throws: NotImplemented IncorrectURL + DoesNotExist + AuthorizationFailed + AuthenticationFailed + TimeOut NoSuccess Notes: - the url specified as in input parameter is to assist the implementation to locate the underlying information system such that it can be queried. + - if the url is syntactically valid, but no + backend service can be contacted at that URL, + a 'DoesNotExist' exception is thrown. + - the semantics for the other exceptions is as + outlined in the SAGA Core API specification. + - note that the session parameter is optional, + as described in the SAGA Core API + specification, section 3.5.2. Also Section + 2.2.2 of the same document applies to + url and its default value. ------------------------------------------

-- Nothing is ever easy.

-- Nothing is ever easy.

Quoting [Steve Fisher] (Dec 18 2008):

...

In the attached version, I tried to address the things we agreed upon, and changed the service types/names table as proposed. Could you give it another pass, please? I left the Constructors untouched for now, until we agreed on something, ok?

Also, there is a question from me at the bottom of page 5:

"Note: Why not TimeOut, AuthorizationFailed, etc??"

For the discoverer constructor, I guess the Authentication exception can be thrown if you don't pass in a session or if you pass in what used to be a valid session that has since expired. How would you class that one?

A session cannot expire - its lifetime is defined by the lifetime of the objects which use that session. If a context (or credential) attached to that session expired, you can expect to see a lot of AuthenticationFailed exceptions, whenever that credential is being used.

Unfortunately quite a lot of the allocation of exceptions is implementation dependent. It would be better to be able to just throw a Security exception - but that is not an option as it is not in the core spec. If you need to get authenticated this could result in a timeout if contact with some remote server is required.

Well, than that is a TimeOut exception :-)) In general, it is of course difficult to map backend exceptions to SAGA exceptions in a meaningful way, but that cannot be avoided really, if the end user is to stay away from middleware exceptions.

In our current implementation, list-services does most of the work and so can throw timeouts and could throw security errors except that we happen to connect to a non-secured information service. However the subsequent calls (such as get_data) can throw the same exceptions as they could choose to go back to the information service to pick up information that was not originally needed when making the selection. If we don't allow the possibility to throw these exceptions the implementation is needlessly restricted. This is why I like the NoSuccess everywhere. In other words I would use NoSuccess for those conditions which are implementation dependent - which in this case is quite a lot.

Good point, so NoSuccess may make sense in all calls. I expected all implementations to simply fetch complete service descriptions, not only parts, but that may have been to limiting. But, is that really the way you expect implementations to work: to fetch some part of the service description, but, e.g., the name and URL just later on, on the get_attribute calls? That adds an awful latency overhead, which easily kills any bandwidth savings, as long as you stay below x.000 returned service descriptions - which is the dominating use case I dare to say. Requiring the implementation to fetch complete desciptions is a certain limitation, sure, but allows more tightly defined semantics for the application and end user... So, that is up to you (I do not know the implementations), but please consider the argument.

For example you have added DoesNotExist for the constructor - implying that the API would contact the underyling information service. However there is no reason why it should do so at this stage.

We have the same problem with the RPC package - there the Constructor has the following note: - according to the GridRPC specification, the constructor may or may not contact the RPC server; absence of an exception does not imply that following RPC calls will succeed, or that a remote function handle is in fact available. and the call() method has the following one: - according to the GridRPC specification, the RPC server might not be contacted before invoking call(). For this reason, all notes to the object constructor apply to the call() method as well. Also, call() has all exceptions of the Constructor, to allow for delayed throws. These notes are, as noted, a result of an underspecification of the GridRPC standard. I would really like to avoid to sprinkle such notes all over the place, as it makes a tight semantic definition of the API rather impossible. I think, if you have no really hard constraints from an underlying standard (as we had with RPC), or from a absolutely dominating implementation, it is not too much to ask from an implementation to ensure in the Constructor if the given (or chosen) URL actually points to a service which is alive and usable - what do you think? Otherwise, indeed, you need to repeat all exception on all calls (which makes catching and error recovery tedious for the application), or map them all to NoSuccess later on (which also gives the application no useful means to recover, e.g. an application does not get the info that a different URL or context may have helped).

...

Nothing is ever easy.

I am inclined to agree

:-)) Best, Andre.

Steve

-- Nothing is ever easy.

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

[...]

Quoting [Steve Fisher] (Dec 17 2008):

2008/12/17 Sylvain Reynaud <Sylvain.Reynaud@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.

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@gmail.com>:

...

Quoting [Steve Fisher] (Dec 17 2008):

...

2008/12/17 Sylvain Reynaud <Sylvain.Reynaud@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.

Quoting [Sylvain Reynaud] (Dec 17 2008):

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 ?),

Yes, right, same here, and for all other namespace based services in any extensions I guess. Best, Andre.

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

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.