upload channels

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

upload channels

Andrew Harrison-2
Hi,

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?

Any help appreciated.

cheers,

Andrew

_______________________________________________
Mozilla-xpcom mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: upload channels

Christian Biesinger
(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.

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: upload channels

Andrew Harrison-2
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
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: upload channels

Christian Biesinger
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
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: upload channels

Andrew Harrison-2
In reply to this post by Andrew Harrison-2
Hi again,

I think I understand now. Could you verify? Having looked at
nsFileChannel, I think what I need to do is:
1. implement an nsIOutputStream that writes to JNI.
2. add a flag to my channel which gets set to true if SetUploadStream
is called.
3. in AsynchOpen check the flag. If true, create an output transport
using nsIStreamTransportService and do a copy from input to output
stream using nsIAsyncStreamCopier.

Am I on the right track?

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
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: upload channels

Christian Biesinger
Andrew Harrison wrote:
> I think I understand now. Could you verify? Having looked at
> nsFileChannel, I think what I need to do is:
> 1. implement an nsIOutputStream that writes to JNI.
> 2. add a flag to my channel which gets set to true if SetUploadStream is
> called.
> 3. in AsynchOpen check the flag. If true, create an output transport
> using nsIStreamTransportService and do a copy from input to output
> stream using nsIAsyncStreamCopier.

I don't really understand why you want an nsIOutputStream... unless your
Java API wants one, maybe? It sounds like it will work, but if all you
want is a byte[], then why don't you, in AsyncOpen, just read all of the
data from the stream into such a byte array, using nsIInputStream::Read
or ReadSegments or something?

The file channel code does what it does because it does want to write to
a stream eventually (the file output stream). It uses the async stream
copier in order not to hang the UI while it writes to the file (don't
know how much of an issue that'd be for you...).


-biesi
_______________________________________________
Mozilla-xpcom mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: upload channels

Andrew Harrison-2

On 24 Nov 2005, at 11:58, Christian Biesinger wrote:

>
> I don't really understand why you want an nsIOutputStream... unless
> your Java API wants one, maybe? It sounds like it will work, but if
> all you want is a byte[], then why don't you, in AsyncOpen, just read
> all of the data from the stream into such a byte array, using
> nsIInputStream::Read or ReadSegments or something?
>
> The file channel code does what it does because it does want to write
> to a stream eventually (the file output stream). It uses the async
> stream copier in order not to hang the UI while it writes to the file
> (don't know how much of an issue that'd be for you...).

I thought of implementing an nsIOutputStream and using the async copier
in order to allow the nsIRequest methods of the channel to query the
copier while an upload is taking place. I'm not sure where methods
these are called from.

_______________________________________________
Mozilla-xpcom mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: upload channels

Christian Biesinger
Andrew Harrison wrote:
> I thought of implementing an nsIOutputStream and using the async copier
> in order to allow the nsIRequest methods of the channel to query the
> copier while an upload is taking place. I'm not sure where methods these
> are called from.

Ah, ok. They are probably called in various places all over the mozilla
code :)

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

identity in XPCOM

Oliveiros d'Azevedo Cristina
All,

Can anyone advise me if the identity rules that applied in MSCOM apply as
well in XPCOM? Namely,
if we query a certain object O1 for nsISupports interface   and store
pointer in p1   and query O2 for nsISupports and store pointer in p2

If O1 == O2  implies that p1 == p2   ?

If this rule doesn't hold how can we test if two interface pointers refer to
the same component ?

Thanks in advance for your help

Oliveiros Cristina

_______________________________________________
Mozilla-xpcom mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: identity in XPCOM

John Bandhauer
In reply to this post by Christian Biesinger
Oliveiros Cristina wrote:
> All,
>
> Can anyone advise me if the identity rules that applied in MSCOM apply
> as well in XPCOM? Namely,
> if we query a certain object O1 for nsISupports interface   and store
> pointer in p1   and query O2 for nsISupports and store pointer in p2
>
> If O1 == O2  implies that p1 == p2   ?

Yes.

>
> If this rule doesn't hold how can we test if two interface pointers
> refer to the same component ?
>
> Thanks in advance for your help
>
> Oliveiros Cristina
_______________________________________________
Mozilla-xpcom mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: identity in XPCOM

Neil Stansbury
Just thought I'd add, in JS you can also:

if ( O1 instanceof Components.interfaces.O2 ) {
        // Do stuff
}

O1 is implicity cast on success


N



John Bandhauer wrote:

> Oliveiros Cristina wrote:
>> All,
>>
>> Can anyone advise me if the identity rules that applied in MSCOM apply
>> as well in XPCOM? Namely,
>> if we query a certain object O1 for nsISupports interface   and store
>> pointer in p1   and query O2 for nsISupports and store pointer in p2
>>
>> If O1 == O2  implies that p1 == p2   ?
>
> Yes.
>
>>
>> If this rule doesn't hold how can we test if two interface pointers
>> refer to the same component ?
>>
>> Thanks in advance for your help
>>
>> Oliveiros Cristina
_______________________________________________
Mozilla-xpcom mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-xpcom
Reply | Threaded
Open this post in threaded view
|

Getting the POST Body

Oliveiros d'Azevedo Cristina
In reply to this post by Christian Biesinger
Hello All,

Is there any way to have Get the Post data from an nsIUploadChannel's
GetUploadStream without actually consuming it ?

I'd like to inspect the data that goes from the browser to the net through
the POST request, but when I read it, through the nsIInputStream -> Read()
method the data seems to get lost and the POSTs don't work.... Should I
somehow re-introduce the data on the input stream again? I've already QIed
the nsIInputStream object for the nsISeekableStream interface, but it
doesn't seem to implement it :(

Any help appreciated

Thanks in advance


Best Regards

Oliveiros

_______________________________________________
Mozilla-xpcom mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: identity in XPCOM

John Bandhauer
In reply to this post by Neil Stansbury
Neil Stansbury wrote:
> Just thought I'd add, in JS you can also:
>
> if ( O1 instanceof Components.interfaces.O2 )    {
>     // Do stuff
> }
>
> O1 is implicity cast on success

The above is a bit misleading in the context of the OP's question. What
you say is absolutely true if 'O2' is the name of an xpcom interface.
But, in the original question I took 'O2' to be an arbitrary object - in
which case your code snippet would not work.

John.

>
>
> N
>
>
>
> John Bandhauer wrote:
>
>> Oliveiros Cristina wrote:
>>
>>> All,
>>>
>>> Can anyone advise me if the identity rules that applied in MSCOM
>>> apply as well in XPCOM? Namely,
>>> if we query a certain object O1 for nsISupports interface   and store
>>> pointer in p1   and query O2 for nsISupports and store pointer in p2
>>>
>>> If O1 == O2  implies that p1 == p2   ?
>>
>>
>> Yes.
>>
>>>
>>> If this rule doesn't hold how can we test if two interface pointers
>>> refer to the same component ?
>>>
>>> Thanks in advance for your help
>>>
>>> Oliveiros Cristina
_______________________________________________
Mozilla-xpcom mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: Getting the POST Body

Christian Biesinger
In reply to this post by Oliveiros d'Azevedo Cristina
Oliveiros Cristina wrote:
> Should I somehow re-introduce the data on the input stream again? I've
> already QIed the nsIInputStream object for the nsISeekableStream
> interface, but it doesn't seem to implement it :(

That's sorta odd because nsIUploadChannel does require an input stream
that is seekable... All mozilla code should pass it one that matches
that requirement... Compare
http://lxr.mozilla.org/seamonkey/source/netwerk/base/public/nsIUploadChannel.idl#57

Where did the upload stream in question come from? Form submission?
_______________________________________________
Mozilla-xpcom mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-xpcom