Hi, Andrew Harrison wrote:
Thanks for your reply. I didn't explain the whole situation. My protocol handler actually calls back into Java using JNI. So the transport I'm using is 'fake', i.e. I get a byte[] from Java and wrap that as a channel. If I want to do the same thing the other way, i.e. send a byte[] to Java, then I need to interface with JNI again. I think I'm right in saying I only have to implement nsIUploadChannel if Im using TCP/IP to send the data, as all nsIUploadChannel provides is an input stream to read from. But if I'm using my own mechanism (i.e. a call to Java) then I think I need to do more I think. Does that make sense?
I don't understand... nsIUploadChannel provides you with an input stream containing the data that should be uploaded. Why can't you read the data from it, store it in a java byte[], and pass that to JNI? Consider file: URLs - clearly, they don't use TCP/IP. But they still implement nsIUploadChannel.
_______________________________________________ Mozilla-xpcom mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-xpcom
