Hi,
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?
cheers,
Andrew
On 23 Nov 2005, at 23:35, Christian Biesinger wrote:
(the netlib mailing list would've been better, btw)
Andrew Harrison wrote:
I've written a protocol handler for a protocol which is based on an
input stream. If this protocol allows sending data as well, via an
output stream, then I'm not sure how this works, for example if I
wanted firefox to understand the protocol scheme from an html form.
Do I need to write an nsITransport implementation? If so, how are
these transports registered with firefox?
No, uploads don't work via nsITransport; transports are for things
like direct socket I/O. It should be enough for you to implement
nsIUploadChannel on the channel that newChannel returns.
_______________________________________________
Mozilla-xpcom mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-xpcom
