[ogsa-dmi-wg] RFC (fwd)

[Mario Antonioletti]

Commnts from Allen:


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


---------- Forwarded message ----------
Date: Thu, 24 Sep 2009 21:53:50 -0700
From: Allen Luniewski <luniew at us.ibm.com>
To: Mario Antonioletti <mario at epcc.ed.ac.uk>
Subject: Re: RFC


Hi Mario,

I am scanning my way through the reference below. Here are my comments.

This is an old one but I stand by it. They are trying to define a
protocol for moving files from multiple sources to multiple
destinations. That is a perfectly fine goal. In the context of DMI there
are two ways of looking at this:

1. First I believe that they could actually do everything they want to
do with no changes to DMI. It would be rather awkward and would result
in a very complex implementation,
but it would be possible to do. I would not go down this route.
2. Second, if they really need a specific protocol for this situation,
it should be done by building a new protocol that addresses this need.
This new protocol would quite
naturally be built on top of DMI.
The point is that DMI was always intended to be a basic a protocol to
move files from a single source to a single destination. And I strongly
oppose any changes to that basic philosophy.

Having said that, we were very vague about the information sent to DTI
factory to create the DTI instance. It was vague enough that we all
agreed that it could easily be used to send multiple files from one file
system to another. But it is a trivial step from there to specifying
files from multiple file systems (if nothing else remotely mounted file
systems give you this). This is why I made comment #1 above.

I am surprised at the comment that DMI is WSRF centric. I thought that
we tried very hard to be neutral on that issue. But this is not my area
of expertise so ...

I am inclined to agree that the transfer options that we defined are
insufficient to meet all cases. However, we also made it fully
extensible via an ANY element so I it is a hard call whether or not it
is appropriate to add the creationFlag element explicitly. I certainly
would not issue a new DMI protocol version just for that! In the case at
hand it is probably sufficient to let it be defined in the higher level
protocol.

In looking at this proposal please keep in mind the distinction between
the abstract problem they are trying to solve (which needs a new
protocol to resolve) and the particular implementation that they have in
hand. Right now I think that they have mixed the two together.

If I were still in the OGF game (which I am not - I am in the surgery
recovery game right now), I would start a WG to define a higher level
protocol to attack the multi-point problem. The solution in the proposal
below is a good start as it addresses the basic issue: how to specify
multiple sources and sinks. The hard question that this WG would need to
address is how to handle status and errors from what are, inevitably.
multiple independent transfers.

Finally, I think that any argument that DMI should be modified in the
way proposed below just to make DMI "more relevant" is an argument with
no value and should be rejected.

I apologize if I have not gone into enough depth on this. My energy
levels are low as are my mental energy levels as my body is clearly
entirely focused on healing from last week's knee surgery. But I will
try and answer further questions in a reasonably timely manner.

Allen Luniewski
IBM WebSphere Commerce
IBM Silicon Valley Laboratory
555 Bailey Ave.
San Jose, CA 95141

408-463-2255
408-218-6998 (mobile)

Inactive hide details for Mario Antonioletti <mario at epcc.ed.ac.uk> Mario
Antonioletti <mario at epcc.ed.ac.uk>