Hi, Chip

I went over the document you sent carefully, and made sure that all the
issues you raised are on the agenda for the upcoming meeting at CERN.
Most of the issues that have to do with directory structures and space
allocations were already on the agenda, since these are the main topics
for this meeting.  I am enclosing here a revised .ppt file for the
discussion of srm v2.1.

Let me be specific about the issues you raised that you recommend be
considered:

1.  Don't use the "srm" prefix.
The reason for this prefix in the use of  "srmGet", "srmPut", and
srmCopy" is that these do not imply the usual ftp "get", "put" and
"copy".  These are more of a request for SRM to allocate space, pin,
etc, before an ftp is performed.  For example "srmPut" allocates space,
and returns location, and then the client can perform the ftp "put".

Now, it may indeed be an overkill for all the other functions.  I added
that issue on the agenda.  But, I am not sure what is the issue with the
OO environment and using srmAnything.  You use terms like "getQuota", so
what's the difference?

2.  Support "list"
Yes, this is already on the agenda for directory operations.

3.  Recursive operations
This is also on the agenda already.  There are 2 places where we will
consider that:
a) in directory operations, particularly ls, rm, rmdir
b) for srmGet, srmPut, and srmCopy.  We are recommending that only
srmCopy will support "recursive".  Perhaps other will think differently.

4.  Add to "list" a "maxCount" and an "offset"
Good suggestion.  I added that to the agenda.

5.  Allow specification of user id for requested operation.
You mean allow specification of user id by the client, right?  We have a
user_ID as part of the request.  I don't see the advantage of allowing
an alias to that in addition.  We already have a user-provided
request_ID that users can use to find the requests they made in case
that they loose the system assigned request_ID.  Can you make a strong
argument (an example scenario) for that?

6.  Make request state an enumeration
In version 2.0, we did not make a distinction between an enumeration and
an arbitrary string, so that additional status codes can be added
without changing the interface.  You say this is a preference.  Is that
an important issue for you?  Why?


Other comments:

1.  GFN - Global File Name
This is the same at LFN.  I personally like the term Global File Name,
but it is so entrenched in the EDG and Globus communities, that it is
not worth the fight.

2.  Make a file Permanent
We have 3 types of files: "volatile", "durable" and "permanent" we
decided in v2.0 to have ChangeFileStatus to include all cases.  Since
we'll have space reservations, and perhaps spaces of three types,
changing a file status may require that the space of that type was
acquired first.

3.  Cost estimation
This is tightly related to monitoring, so for now we can only do so in a
crude fashion.  We should probably have it in v2.1 as a place holder

4.  Get Quota
This is more complex now that multiple types of spaces may be permitted
and negotiations of quotas will be permitted.  I expect that we'll have
additional functions, such as checking on remaining quota space, etc.

5.  Optional arguments, optional returns
You said that in v2.0 it is intended.  But we have that explicitly
expressed as "null OK?" in the tables.

6.  File information
You say: add modification date to what is in V1.0.  Do you mean in case
that a file is modified?  We stayed out of modified files so far.  This
is a big issue, with coordination of copies with "master file" etc.  We
should probably address this at some future time.

7.  Request ID status
We have that, but in your table, you left it empty under column "draft
v2.0.

8.  Array of filename support
I'd rather refer to "a set of files", since array implies an order.  At
this time we do not consider support for ordered multi-file requests.


Thanks for your comments.  I think your J-SRM version is very close
already, and I believe the new version v2.1. will address all your
suggestions and comments.

Arie.