[ogsa-dmi-wg] Proposals

[Michel Drescher]

Hi all,

some comments from me inline:

On 4 Dec 2007, at 23:48, Allen Luniewski wrote:
> [...]
>
> 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 agree that the second proposal is of less controversy.
However, I would argue that the concept of retrying a data transfer  
should not be different in its semantics from a single attempt to  
transfer data. The proposal of integrating the number of retries in  
the transfer requirements seem fine.

But I would not want to introduce a new state reflecting that  
previous attempts have failed. I'd rather propose another optional  
DTI attribute that indicates how many attempts have failed already.

Regarding the effects on failed, partial attempts I would also argue  
not to change the overall semantics. For this I see two suitable  
alternatives:
a) Leave it as an implementation detail on how exactly the DTI  
handles failed attempts as long as the overall semantics are kept, or
b) we explicitly require that each failed attempt MUST abide by the  
rules laid out for the cleanup rules given for the chosen data  
transfer protocol.
Personally, I would prefer option b.
>
> 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.
>
I second this entirely.

Cheers,
Michel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.ogf.org/pipermail/ogsa-dmi-wg/attachments/20071205/8cc19fd0/attachment.bin