[EMAIL PROTECTED] schrieb am 04/09/2008 12:17:29 AM: > Thanks for letting us know. I just installed this in my eclipse and > used it. Very handy little tool to gridftp stuff to my argonne > machine. Are there any plans for improving this to 3rd party using > drag-and-drop ? Is it already there and I just could not figure it > out ? May be we can also integrate it with RFT too. > > Good work.
Thank you. Drag-and-drop (between the server views) is not implemented yet, but has been planned ;-) pretty much from the beginning. If you mean dragging of files from the local disk (from other Eclipse views or external applications), that will probably have to wait longer because it depends on the client-to-server transfers to be implemented first. Check out the Requested Features tracker at https://sourceforge.net/tracker/?group_id=221662&atid=1052833 to see what is planned and to post your enhancement requests or remarks. There is indeed a significant overlap in the functionality of our GridFTP Client and RFT. We've not used RFT so far because we wanted something that end users could install on their machine to quickly work with no dependencies and because of the time-to-"market" considerations: with full control over the code base we could quickly work around issues such as insufficient dCache compatibility or improve timeout handling in JGlobus without too much coordination delays. I think that our transfer state machine with retry/resume on an individual file level and classification of server error messages into fatal/non-fatal might be more elaborate than RFT's. On the other hand, RFT has been tested more extensively and is as widely deployed as Globus. Our present plan is to make our transfer manager component more independent from the GUI. This refactoring is needed in any case. Once that is done, our transfer manager should be deployable much like RFT (we are reinventing the wheel, but it's a small wheel). Then there will still be the dilemma whether it makes more sense for the client to use our own standalone transfer manager or RFT as backend. Another service that we wish to examine in this context is SRM v2. The main decision factors will likely be the effort-to-implement and the ability to keep the GUI as responsive and informative as it is possible with a tightly integrated transfer manager. (I kept [EMAIL PROTECTED] in cc for consistency, but perhaps it should be dropped from the rest of this message exchange to avoid clutter.) Regards, Jan Ploski
