I have looked at Ravi's proposals and would like to offer some comments. The second proposal, on retries, basically seems okay to me. I suspect that there is an issue to be addressed regarding what is done with data that is partially transferred when a transfer is retried. But, perhaps, that is covered if the operation eventually succeeds (presumably no orphan data) or fails (covered by the DMI spec regarding cleanup after failure). I have serious concerns about the first proposal, for multiple objects to be transferred. I see two major problems: 1. The proposal makes no restrictions on what the source/sink DEPRs refer to. Ravi's clear goal is that they refer to different objects on the same server. However, the proposal makes no such restriction. Thus the proposal admits to the N sources being on N different servers, perhaps widely separated both geographically and organizationally. The complications that this creates for the DTF and DTI are almost unimaginable and, I feel, uncaccpetable. I see no way to make a simple change to this proposal to address this problem. 2. There is nothing in the proposal that ties a particular source DEPR to a particular sink DEPR. Since the source/sink sequences are ordered, perhaps the desire is to make the connection via that ordering. Thus this can probably be handled fairly simply. As a mater of principle, I think that this whole issue is not one that the DMI spec either should or needs to address. Rather, the multiplicity of entities to be transferred should solely be an issue to be addressed by the client when getting the DEPR from the source (sink). The source (sink) should mint the DEPR in a way that encodes the multiplicity of entities to be transferred. Then, when the DTF and DTI pass that DEPR back to the source (sink) it can take the DEPR apart and properly handle the multiplicity of objects. I can see backing away from this rigid approach to allow ***implementations*** of a DTI to be aware of the way that certain DEPRs are minted (e.g., if we are transferring multiple files, the source/sink file systems and the FTP DTI could agree on the way multiple files are denoted in the DEPRs). In either case, it should not be the responsibility of the DMI spec to specify this behavior. Allen Luniewski IBM WebSphere Cross Brand Services IBM Silicon Valley Laboratory 555 Bailey Ave. San Jose, CA 95141 408-463-2255 408-930-1844 (mobile) Ravi Madduri <madduri@mcs.anl. gov> To Sent by: ogsa-dmi-wg@ogf.org ogsa-dmi-wg-bounc cc es@ogf.org Subject [ogsa-dmi-wg] Proposals 12/04/2007 02:24 PM Hi Please find attached my proposals to include more than one source/sink pairs in the RequestDataTransferInstance and another proposal to include the retry information in the transfer request. I can talk about the proposal more in tomorrow's call Thanks [attachment "DMI_Proposal_Retries" deleted by Allen Luniewski/Almaden/IBM] -- Ravi K Madduri The Globus Alliance | Argonne National Laboratory | University of Chicago http://www-unix.mcs.anl.gov/~madduri -- ogsa-dmi-wg mailing list ogsa-dmi-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-dmi-wg
