Summary: | [Net] Utils for responsive network I/O should be pushed down | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Martin Oberhuber <mober.at+eclipse> |
Component: | Team | Assignee: | Platform Team Inbox <platform-team-inbox> |
Status: | ASSIGNED --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P5 | CC: | alex.blewitt, Michael.Valenta, robert.elves, sdavids, Szymon.Brandys, wmitsuda, wojciech.galanciak |
Version: | 3.3 | Keywords: | api, helpwanted |
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Bug Depends on: | |||
Bug Blocks: | 173619 |
Description
Martin Oberhuber
2007-02-09 04:06:01 EST
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. |