[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [geclipse-dev] File Transfer Service / 3rd Party Transfers
|
Stuempert, Mathias wrote:
Hi Mateusz,
Hi Mathias,
Welcome back from holidays :-)
>> When gEclipse file system will be asked to perform a file transfer,
first
it will look if there is any plugin that registered this transfer
configuration (e.g. SRM->SRM).
What about 3rd party transfers across different EFS implementation, e.g.
GSIFTP->SRM, which should be possible since GSIFTP is the transport
layer for SRM as far as I know, right?! The problem here is that
eu.geclipse.efs.gsiftp may then need knowledge of eu.geclipse.efs.srm.
In that case that would introduce a cyclic dependency since efs.srm
already depends on efs.gsiftp, right? Even if this specific example may
not be valid this is definitely a use case that may cause problems. So
please think about it before starting with any mature implementation.
It's all up to the plugins. If plugin decide that it can handle
GSIFTP->SRM transfer the go ahead and register itself in the transfer
service repository. SRM plugin itself should not register itself in this
manner since there is no SRM way to do such a transfer (at least I don't
know it).
If there is such a way, then there should be a new plugin that depends
on both GSIFTP and SRM plugins. No cycles.
GSIFTP alone is not able to perform a transfer to SRM. Even, as you say,
GSIFTP is a transfer protocol for SRM - that means SRM invokes
GSIFTP->GSIFTP transfer.
Transferring a file from GSIFTP to the SRM will invoke GSIFTP->SRM
transfer, then SRM will delegate it to the GSIFTP. But I don't expect to
provide 3rd party transfer in this special case. (but it's somehow
possible).
Before transfer begins, some informations about it will be stored in
persistent Eclipse repository. When g-Eclipse will be restarted (or
after
crash), the 3rd party transfer mechanism will resume all the transfers
which didn't finish in the previous session. It will be an EFS
plugin's
duty to check if the transfer was successful or not.
What about server/service-driven 3rd party transfers? Not sure if this
applies to any of our current implementations but definitely it may be
the case that a middleware provides a service for such transfers. In
that case g-Eclipse only initiates the transfer from the client side but
the transfer itself is made on the server side and even continues when
g-Eclipse is shut-down. Also something you should keep in mind here.
The solution was designed with this in mind too. That's why this
persistent repository is for. Transfers of fire-and-forget type are very
welcome. With this type of transfer, staring geclipse will just check if
the transfer was done.
Concerning the technical side I am curious how this will be implemented
on the MW-independent side. I guess this has to be covered by our UI's
transfer operation? Or will you provide a completely new mechanism here?
Obviously the transfers should be implemented in the
EFS-implementation's copy/move-methods. Are these already used by our
transfer operation? I do not know the current implementation but the
initial implementation made use of the IResource methods for copying
files. So this may also be a subject of change then.
I think about new mechanism that in the end will rely on copy/move
methods. The reason is that SRM is able to perform 3rd Party Transfers
to some implementations only. So declaring SRM->SRM transfer is just a
approximation of ability ;-)
according to:
http://datagrid.lbl.gov/v22/index.html
--
Mateusz Pabiś
