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@us.ibm.com> To: Mario Antonioletti <mario@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@epcc.ed.ac.uk> Mario Antonioletti <mario@epcc.ed.ac.uk>