Community
Participate
Working Groups
In a first step open the remote files in read-only mode in a proper editor. - Text-type files should open in a internal Eclipse editor by default plus allowing the user to choose the system editor. - Binary, non-executable files (.png and similar) should open in the system editor if one is associated. - Binary, executable files should optionally open in a nice read-only hex editor, if there is one. If not, open this kind of files should be prevented.
Cool! I assume you'll be able to save the files to the remote in a future step?
Yes. Editing the file and saving the modified content back to the remote target will be a second step and I'll open a separate bugzilla for it too.
(In reply to comment #2) > Yes. Editing the file and saving the modified content back to the remote target > will be a second step and I'll open a separate bugzilla for it too. Very cool :).
Created attachment 199081 [details] The patch of the fix. Hi Uwe, I created a fix for this bug and attached its patch here. Could you please have a review? The basic idea is that the file is downloaded to a local cache folder before it is opened. The last modified time stamp of the cache file will be set to the same value to that of the remote file. Next time the file is requested to be opened, it checks if the local cache file exists and if the time stamp is the same as the remote file. If it is, then the local cache file will be opened. Or else, it will be downloaded again and then opened. Technically, a URLStreamHandlerService is registered in the plugin's activator. Every remote file is associated with a URL with the following format: tcf:///<TCF_AGENT_PEER_ID>/remote/path/to/the/file The stream handler then creates TcfURLConnection and opens TcfInputStream for streaming. The implementation of TcfInputStream pumps the data from the remote system using TCF channel APIs. In the future when the feature of saving files is implemented, this stream protocol could be expanded with an TcfOutputStream to do output streaming. The reason to use URL API is that I think it is simple, flexible, and easy to be extended. When the file to be opened is too large, a time triggered progress dialog will pop up to display the downloading progress. The downloading of a large file could be canceled using the progress dialog. The "Open" menu will show only when the selected file is not a binary file. The content type parsing is based on file name extensions so that the testing is fast enough. -William
Created attachment 199086 [details] Modified patch William, I've attached a slightly modified version of your patch, fixing some build issues and NPEs. Please resync your local versions with the modified patch. 1. The TCFInputStream implementation is using Java 6 API. Not sure how that builds in your workspace, but the API level for the TE project is still on Java 5. 2. On Windows, the constructed URL is malformed. You get something like "tcf:/<peer id>C:\Temp/x.txt". As the peer id cannot be extracted anymore correctly, you run in a lot of NPEs trying to open the file. I've modified the construction and parsing slightly to deal with it. If you agree with this changes, I'll go ahead and commit the patch. Thanks, Uwe
Hi Uwe, I've examined your changes to the patch. Yes, I agree with you on the changes. Please go ahead and commit it. Thanks! -William
I, William Chen, declare that I developed the attached code from scratch, without referencing any 3rd party materials except materials licensed under the EPL. I am authorized by my employer to make this contribution under the EPL. -William Chen
Committed patch.
I think the original patch should not be "obsolete" and should be iplog+
