Streaming support - use cases?
I am working on adding support of adding the ability to send InputStreams via remoting. I have the basics working, but am struggling with how to expose this via the API.
The concept is that if a user wants to pass any InputStream type to the server, the remoting framework will keep a reference to that stream on the client side and create a server component wrapped around that InputStream. Then will call on the server side to let it know it has an InputStream available and create a proxy on the server side to that InputStream on the client (which calls back on the server component created). The user handler on the server side is just given that InputStream proxy, which is typed as an InputStream so can call on it as though it was a local InputStream. I have all this working.
So now onto the questions.
1. Requirements for accessing the client over the network. Right now, the requirement would be that the server MUST be able to make calls directly to the client in order to reach that callback component for the client's stream. I don't see any other way to do this at the moment. Is this an acceptable requirement?
2. What should the client API for this call look like? I would prefer to make this a seperate method within the Client class (i.e. stream(InputStream stream)). This makes it much easier to process because I know I am dealing with a stream explicitly. The only problem is just sending an InputStream to the server handler does not provide much context as to what to do with it. Also requires the user code on the client to know it is sending an InputStream (which I feel comfortable with as a requirement).
The other way to do this would be to just call on the existing invoke(Object param) method and pass the InputStream as the param. This is easier from the client coding side, but will require a check on the param to see if it is of type InputStream (so extra overhead which is probably not often needed). Then under the covers, can process it as would the stream(InputStream stream) method.
Once again, still have the problem of the server handler just getting the stream without any context as what to do with it. So another, more difficult option, would be to inspect the entire object graph for any param passed in the invoker(Object param) method and try to see if it contains an InputStream at any level and handle it. This option is almost impossible because even if can find that one of the object reference within one of the member variables of param object is of type InputStream, can not be sure that I will be able to remove it and replace with the wrapper. The only way I can think to do this is to use AOP and would then not make it into the next release of remoting.
3. When to close the stream? My idea was to wait till the server handler called close() on the stream proxy and then close it on the client side. Only problem is in the case there is some sort of network error where the server can not reach the client and the client's real InputStream never gets closed. Should there be some sort of timeout based around this?
Please provide any input you might have on this and will try to get this knocked out within the next week for the remoting release.
