Community
Participate
Working Groups
Platform/Team has some excellent, well-tested utility classes for responsive interruptible network I/O: http://eclipselowdown.blogspot.com/2007/01/responsive-remote-connections.html In the context of creating a common preference page for proxies in the Platform, Alex Blewitt brought up the idea that some of these should be pushed down into the Platform (bug 154100 comment 74). These utilities fix a problematic shortcoming of the Java API for Eclipse. Potential users include at least the update manager and the dsdp target management project (we currently copy some of the classes to our own project). http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.team.cvs.core/src/org/eclipse/team/internal/ccvs/core/util/Util.java?revision=1.48&view=markup http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.team.core/src/org/eclipse/team/internal/core/streams/PollingInputStream.java?revision=1.11&view=markup http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.team.core/src/org/eclipse/team/internal/core/streams/TimeoutInputStream.java?revision=1.8&view=markup At least if these can't be pushed down to a suitably generic level, can there be factories created which can then plug in this kind of implementation in the future?
Given that it's Michael who has been talking about those classes, he should probably be on this bug (but then, I suspect that he's part of platform-team-inbox anyway ...) 3.3M5 is due out Real Soon Now, and afterwards any API changes have to get signed off; so this would have to be dealt with pretty quickly if this were going to be pushed down towards a more generic place. Would Jeff McAffer be the person to discuss this with?
It seems too late for 3.3M5, but the API of these seems sufficiently clear and stable that I'd hope this could even be pushed down for M6. One could argue that these helpers are small enough (and under EPL), such that anybody can just copy them. We did this for createSocket() for now, though we hope we can get rid of our own version and use a common one instead - see http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tm.rse/plugins/org.eclipse.rse.services/src/org/eclipse/rse/services/RemoteUtil.java?revision=1.1&root=DSDP_Project&view=markup Besides not being nice, one negative impact of this is that any NL strings to be translated now pop up in multiple places, unnecessarily impacting the translation process. BTW, other places where I've seen ugly timeouts is in file and directory browse dialogs (when the file systems are shared from a slow network), and input boxes when typing a filename (particularly ugly when each keypress has a long timeout because the dialog verifies whether the file actually exists on a networked slow file system or not).
We are past our API freeze for 3.3 but we will consider this for the next release.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
