Implementing an nsIChannel

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

Implementing an nsIChannel

Neil Stansbury-2
Hi all,

I am writing an object model for some XML based protocols I am
implementing in XPCOM.

One can be accessed via RPC style SOAP, another via standard encoded
strings, the last by standard XML messages. As there are many higher
level similarities I am looking to abstract each as much as possible.

One mechanism I'm looking at is to implement a new nsIChannel that
handles the specifics of each communication method, that wraps a lower
level nsIChannel (it may or may not be nsIHttpChannel). That way I have
a common way to read/write data for each.

There are however lots of holes in this concept, can someone explain the
theory behind the nsIChannel imp please? The netlib docs of this area
are "todo".

Should I be looking to do this or are there better mechanisms? Is there
a standard way of wrapping XML protocols on top of nsIChannel/SOAP
implementations?

Cheers,

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

Re: Implementing an nsIChannel

Boris Zbarsky
Neil Stansbury wrote:
> There are however lots of holes in this concept, can someone explain the
> theory behind the nsIChannel imp please? The netlib docs of this area
> are "todo".

A channel is something that has a URI and that you can open and pass an
nsIStreamListener to.  After you have done so, it will eventually call back to
the nsIStreamListener you passed to it (calling
OnStartRequest/OnDataAvailable/OnStopRequest on it).

Wrapping one channel in another one is quite doable if you want to.

Past that, the question is so vague that I'm not really sure what to say.  What
specific issues are there that arise when you try to do it?

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

Re: Implementing an nsIChannel

Neil Stansbury-2
Hi Boris,

Apologies for the vagueness I didn't want to bore anyone!

Ok, I am merging our "Mozilla for GroupWise" and "Liaison Projects".
Both communicate with Novell's GroupWise email system via different
methods. The original (that must be maintained) is URL encoded streams
and XML messages, the new mechanism is SOAP. I am trying to marry the
two together so I can remove duplicated code.

For example in "Message.Delete()", I don't want to have to write this
method for each underlying XML protocol. I'd rather have the underlying
"datastore" (this where nsIChannel came in) handle the specifics of
deleting the message using either the URL encoded, XML message or SOAP
RPC style as needed.

My conceptual problems were:

I had figured out that channels are a "single shot" data connection. So
I need to handle the concept of being "connected" in my channel.

SOAP doesn't appear to use channels, or stream listeners so I'm some
what forcing a square peg into round hole.

How do I convey a URL encoded stream into my custom channel for writing
to the underlying one. I'm not sure if an XML message is best written
via a nsIStreamListener anyway. Perhaps it's overkill and provides
little value.

This is all very conceptual, and am struggling with the object model as
much as anything.

Having looked at the new mozStoragexxx interfaces, I am tempted to
create a more abstract "StorageConnector" with "Write()" and
"AsyncWrite()" methods, and a similar "ValueArray" concept.

What got me thinking along this was seeing the other channel imps:
nsIJARChannel, nsIFTPChannel, nsIFileChannel, nsIHttpChannel. I kind of
assumed all the SQLLite interfaces in the new mozStorage interfaces
would probably be implemented as an nsISQLChannel and that perhaps I
could add an "XML Channel layer" above them all.

Thanks for the thoughts,

N


Boris Zbarsky wrote:

> Neil Stansbury wrote:
>> There are however lots of holes in this concept, can someone explain
>> the theory behind the nsIChannel imp please? The netlib docs of this
>> area are "todo".
>
> A channel is something that has a URI and that you can open and pass an
> nsIStreamListener to.  After you have done so, it will eventually call
> back to the nsIStreamListener you passed to it (calling
> OnStartRequest/OnDataAvailable/OnStopRequest on it).
>
> Wrapping one channel in another one is quite doable if you want to.
>
> Past that, the question is so vague that I'm not really sure what to
> say.  What specific issues are there that arise when you try to do it?
>
> -Boris
_______________________________________________
Mozilla-netlib mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-netlib
Reply | Threaded
Open this post in threaded view
|

Re: Implementing an nsIChannel

Boris Zbarsky
In reply to this post by Neil Stansbury-2
 > I had figured out that channels are a "single shot" data connection. So
 > I need to handle the concept of being "connected" in my channel.

Yes, channels are single-shot things.

 > SOAP doesn't appear to use channels, or stream listeners so I'm some
 > what forcing a square peg into round hole.

I think SOAP uses XMLHttpRequest, which does use a Necko channel.

I'm still trying to understand your setup.  You're implementing a protocol
handler, right?

 > I kind of assumed all the SQLLite interfaces in the new mozStorage interfaces
 > would probably be implemented as an nsISQLChannel

Only if there is actually a networking protocol associated with it...

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

Re: Implementing an nsIChannel

Neil Stansbury-2
>> I think SOAP uses XMLHttpRequest, which does use a Necko channel.

Oh ok, I couldn't find a SOAP method that gave me access to those
interfaces. I'll look again.

 >> Only if there is actually a networking protocol associated with it...
Ok, I figured it'd work just like a JAR file: sql:path/to/db.sql!

Though, understanding it a bit better now, perhaps representing a DB
connection as a stream isn't neccesarily the best way.

>> I'm still trying to understand your setup.  You're implementing a
>> protocol handler, right?

Yep an XML message/rpc protocol, using (usually) HTTP as a transport.

Just to clarify my thinking. I have an XPCOM object representing an
email "Message" for example, with a "Delete()" method.

One server side mechanism expects a plain URL encoded GET, eg.

http://host.domain.com?session=abcd&action=message.delete&message.id;

The response is a simple <xml tag> encoded in the body.


The other mechanisms require a SOAP style XML message POSTed to a URI:

<removeItemRequest>
  <container>some-containerid</container>
  <id>unique-item-id</id>
</removeItemRequest>


I don't want to have to implement multiple Message.Delete() methods for
each underlying XML format. I wanted to transfer a generic request of
Delete() to the "channel" for that connection, and then have it handle
the "Delete()" specifics for that connection type.

Cheers,


N



Boris Zbarsky wrote:

>  > I had figured out that channels are a "single shot" data connection. So
>  > I need to handle the concept of being "connected" in my channel.
>
> Yes, channels are single-shot things.
>
>  > SOAP doesn't appear to use channels, or stream listeners so I'm some
>  > what forcing a square peg into round hole.
>
> I think SOAP uses XMLHttpRequest, which does use a Necko channel.
>
> I'm still trying to understand your setup.  You're implementing a
> protocol handler, right?
>
>  > I kind of assumed all the SQLLite interfaces in the new mozStorage
> interfaces
>  > would probably be implemented as an nsISQLChannel
>
> Only if there is actually a networking protocol associated with it...
>
> -Boris
_______________________________________________
Mozilla-netlib mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-netlib
Reply | Threaded
Open this post in threaded view
|

Re: Implementing an nsIChannel

Boris Zbarsky
Neil Stansbury wrote:
> Oh ok, I couldn't find a SOAP method that gave me access to those
> interfaces. I'll look again.

There might well not be one....

>>> I'm still trying to understand your setup.  You're implementing a
>>> protocol handler, right?
>
> Yep an XML message/rpc protocol, using (usually) HTTP as a transport.

No, what I meant is that you will actually have URIs like "my-scheme:something"
around?  Or is that still being decided?

> I don't want to have to implement multiple Message.Delete() methods for
> each underlying XML format. I wanted to transfer a generic request of
> Delete() to the "channel" for that connection, and then have it handle
> the "Delete()" specifics for that connection type.

Ah, hmm... Let me think on that.

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

Re: Implementing an nsIChannel

Neil Stansbury-2
 > No, what I meant is that you will actually have URIs like
 > "my-scheme:something" around?  Or is that still being decided?

Ah ok sorry. I was thinking about that initially, but I decided that
there are going to be more of these once I have the object model sorted,
so the schemes may end colliding. I did feel it wasn't particularly
elegant as well. So it will just be whatever the standard nsIChannels
support (http:/ftp:/file: etc).

 > Ah, hmm... Let me think on that.
Cool thanks. For me the question is if I go with a generic storage
connector for each access "protocol", how to handle read and writes.

Calling Connector.Write( nsIStreamListener ); Might work but then each
connector needs to serialise in/out the data.

The best concept I have thus far is similar to the new
mozIStorageValueArray, an quad array of values.

A quad because each value needs to represent an RDF Triple, plus the
value changing (if any). I haven't found a way to ref a unique RDF arc
without the entire triple (one for Axel I guess) so:

RDF S/P/O: message.id, message.subject, "subject", "new subject"

Cheers Boris,

N


Boris Zbarsky wrote:

> Neil Stansbury wrote:
>> Oh ok, I couldn't find a SOAP method that gave me access to those
>> interfaces. I'll look again.
>
> There might well not be one....
>
>>>> I'm still trying to understand your setup.  You're implementing a
>>>> protocol handler, right?
>>
>> Yep an XML message/rpc protocol, using (usually) HTTP as a transport.
>
> No, what I meant is that you will actually have URIs like
> "my-scheme:something" around?  Or is that still being decided?
>
>> I don't want to have to implement multiple Message.Delete() methods
>> for each underlying XML format. I wanted to transfer a generic request
>> of Delete() to the "channel" for that connection, and then have it
>> handle the "Delete()" specifics for that connection type.
>
> Ah, hmm... Let me think on that.
>
> -Boris
_______________________________________________
Mozilla-netlib mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-netlib
Reply | Threaded
Open this post in threaded view
|

Re: Implementing an nsIChannel

Boris Zbarsky
In reply to this post by Neil Stansbury-2
Neil Stansbury wrote:
> I don't want to have to implement multiple Message.Delete() methods for
> each underlying XML format. I wanted to transfer a generic request of
> Delete() to the "channel" for that connection, and then have it handle
> the "Delete()" specifics for that connection type.

This really doesn't sound like something an nsIChannel is suited for, the more I
think about it.  Sounds like some new sort of interface/object would be needed...

-Boris
_______________________________________________
Mozilla-netlib mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-netlib