Summary: | [EFS][Doc] Add Javadoc how concurrently open Streams should be handled | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Martin Oberhuber <mober.at+eclipse> | ||||
Component: | Resources | Assignee: | Szymon Brandys <Szymon.Brandys> | ||||
Status: | RESOLVED FIXED | QA Contact: | |||||
Severity: | enhancement | ||||||
Priority: | P3 | CC: | john.arthorne, Szymon.Brandys | ||||
Version: | 3.3 | Keywords: | helpwanted | ||||
Target Milestone: | 3.5 RC1 | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Martin Oberhuber
2007-08-02 10:59:18 EDT
1 and 2 sound reasonable. For 3, I don't like the idea of creating an arbitrary limit. A very simple client could function on an implementation that only supported a single connection, so it would be overly restrictive to define such a limit - it would prevent certain uses that would otherwise be fine. Ok, so it looks like to improve the Javadoc for IFileStore#getInputStream() IFileStore#getOutputStream() in the following ways: 1. Tell clients that the number of concurrently open Streams can be limited, the limit can depend on the Provider, and may be as low as only 1; so, the client should close the Stream as soon as it can 2. Specify that a CoreException can be thrown when no more Streams are available 3. Specify that providers _may_ enqueue the get*Stream() request in case no Streams are available, such that they wait until a Stream becomes available or the (maximum timeout?) expires and they fire a "no more streams" CoreException. We may want to discuss what that timeout could be, perhaps it should be free for the provider to choose. At any rate, while the Provider waits for a Stream, it should periodically check the IProgressMonitor so the request can be canceled when it takes too long. Because these are all changes of Javadoc, I changed the Summary to more clearly reflect what we want (previous value was: "Need advice how providers should handle multiple open streams") Looking at the FileStore#copy() implementation, which is also referenced by FileStore#move(), it seems that the minimum requirement for a proper EFS provider is to support 1 InputStream 1 OutputStream in parallel (or, the provider would need to override the copy() and move() operations such that it works with a single Stream only). Martin, are you considering providing the patch? We're past the time for this kind of item for 3.4. Please move milestone. I think that the EFS chapter in the dev guide should be updated along with javadocs. It's not too late for such bugs, however I will take care of it during 3.5. Created attachment 134609 [details]
Proposal v01
+1. The only change is "has exceeded" should be changed to "has been exceeded". Thanks John. The update to javadoc released to HEAD. |