Community
Participate
Working Groups
There should be a generic up/downlad that works with files and directories. I wrote my own one (and every other user of RSE is likely to the same). Sample code for upload is attached. I, Lothar Werzinger, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer to make this contribution under the EPL.
Created attachment 53009 [details] sample upload implementation
I believe that enhanced up/download will be added to RSE 2.0 as part of putting the IBM Import/Export wizards into Open Source. Correct, Dave?
To clarify. I was thinking to extend IFileServiceSubSystem and IFileService to have generic methods for up/download. This could live in an abstract base class that Service implementations derive from to avoid code duplication. I'm not sure if that would be covered by the IBM Import/Export wizard contribution.
This would not be covered by the import/export contribution, but the idea is a good one. Dave McKnight should review after R1.
Dave -- I'm assigning to you. Seems like your area.
This looks similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=162195. I agree that we should do this but due to the API change it has to wait until 2.0.
As per my comment on bug 162195, I'm not so sure that bulk upload/download should really go into the service. The idea of IFileService is that it provides the most basic functionality and is easy to implement. I do not think that implementing a bulk upload in the service would give a lot of performance improvement over a bulk upload at a higher level - provided that the implementation at a higher level is optimized well, which will benefit all services immediately.
As pointed out in https://bugs.eclipse.org/bugs/show_bug.cgi?id=162949#c3 I expect that there would be a common implementation that all implementations would benefit from. The higher levels of RSE seem always to do some user interaction (e.g. Dialog on failure, etc.) and that may not what the user/application wants. So a generic solution at this level that just throws an exception so that the app code can handle it how he likes it may have its benefits, too. That does not mean that there can not be a higher level call that wraps this low level one with nice user interactions. On the contrary I'd expect to have such a call, too.
Any changed opinions on this now that we have methods for getting input and output streams at the IFileService layer?
What's the difference between the contribution suggested here, and the existing UniversalFileTransferUtility which we explained in our EclipseCon tutorial?
UniversalTransferUtility does provide the facility to do transfers on directories and files via the subsystem layer and using temp files. At this layer file transfers are done between IResources and IRemoteFiles, timestamps and other temp file properties are handled here as well as conflict checking.
When I get comment #8 right, the request is for a UniversalFileTransferUtility that has the following characteristics: 1. It works for any files and directories but is not tied to IResource 2. It throws exceptions in case of failure, no dialogs or user interaction Does such a utility exist already, or can we refactor the existing one such that there is a low-end service part (as requested here) plus the hi-end driver doing user interaction and IResource mapping like the current UniversalFileTransferUtility?
We don't have a utility class right now that is not tied to IResource. The next layer down is the subsystem layer, itself. The reason I created this class in the first place was just to help take care of some of the temp file stuff that we do with IResource (such as setting timestamps in IFile properties). I suppose we could split this into a low and high end service although we'd have to be careful that people don't use the low end when they should be using the higher end.
Not for 2.0
