Community
Participate
Working Groups
I thgink RSE should not use String parameters for paths and filenames. Example: http://127.0.0.1:59548/help/topic/org.eclipse.rse.doc.isv/reference/api/org/eclipse/rse/services/files/IFileService.html#copy Why not use something like IPath. That would condense two arguments into one and the user would not have to worry about directory separators in the strings etc.
Need to look at this after 1.0
The RSE Services Layer is meant to be used also in contexts other than Eclipse, so IPath / Path is probably not the best choice. Still, I'm not totally against getting rid the "String" arguments since all the path handling is pretty clumsy right now. Deferring to Future for now.
One problem with passing (String) parentDir, fileName into the IFileService is that some methods require more information about the actual file to be handled: * Download may want a file size to use in a progress monitor * setReadOnly might want current file attributes * mkDir, chDir might want to know if working on a file or directory The upper RSE layers tyipcally do have that information, because they use getFile() in order to retrieve IHostFile objects and maintain them. These IHostFile objects should be passed back into the service in order to allow for more efficient service implementations. In FTP, for instance, a small stat cache had to be implemented by bug #198638 in order to avoid unnecessary LIST commands in FTP just for getting file size and similar. That stat cache would be unnecessary if the API were properly set up. Note that when IHostFile objects are being passed into the service, the service would need to verify it's a proper IHostFile object (e.g. not too old) before using its data without further host query. The actual IHostFile implementation would potentially need to carry a timestamp to know when it was created.
