211718 - Implement simple protocol handler object

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[Adam Lock]

wxEmbed contains a class that makes it easy to register new protocols that
return a chunk of data. The called registers a callback with a single GetData
method which is called when Gecko tries to load a URI with the registered scheme.

http://lxr.mozilla.org/seamonkey/source/embedding/tests/wxEmbed/GeckoProtocolHandler.h
http://lxr.mozilla.org/seamonkey/source/embedding/tests/wxEmbed/GeckoProtocolHandler.cpp

This should be cleaned up and wrapped in an XPCOM service and spun off into
embedcomponents or necko. The callback should be renamed something like
nsISimpleProtocolHandlerCallback. The RegisterHandler static method in the
header should become an inline NS_RegisterSimpleProtocolHandler() which gets the
simple protocol handler service and registers the supplied callback.

The GetData method on nsISimpleProtocolHandlerCallback should also be
supplemented or extended to allow the embedder to return an nsIInputStream
object instead of a memory block.

Comment 1

[Adam Lock]

Attachment: nsISimpleProtocolHandler.idl

IDL for nsISimpleProtocolHandler and nsISimpleProtocolHandlerCallback.

I still have to add a getStream method to the callback for embedders who want
to return a stream (e.g. a local file, or a stream they got from somewhere
else).

Comment 2

[Adam Lock]

Attachment: nsSimpleProtocolHandler.h

Header for simple protocol handler

Comment 3

[Adam Lock]

Attachment: nsSimpleProtocolHandler.cpp

Implementation of simple protocol handler

Comment 4

[Adam Lock]

Attachment: winEmbed sample

Sample use of simple protocol handler with winEmbed. Caller gets the simple
protocol handler service, registers the 'foo' scheme with a supplied callback.
The callback returns some simple 'text/html' content.

Patch also contains plumbing to embedcomponents to build & register it.

Comment 5

[Adam Lock]

Doug / Darin, can I have a review on this please? Thanks

Comment 6

[Darin Fisher]

Comment on attachment 127049 [details]
nsISimpleProtocolHandler.idl

> * The Initial Developer of the Original Code is 
> * Netscape Communications Corporation.
> * Portions created by the Initial Developer are Copyright (C) 1998
> * the Initial Developer. All Rights Reserved.
> *
> * Contributor(s):
> *
> *   Adam Lock <[e-mail]>

copyright info needs to be updated...


>    [noscript] void getData(in nsIURI aURI,
>				 in nsIChannel aChannel,
>                 out ACString aContentType,
>				 out charPtr aData,
>				 out unsigned long aSize);

nit: fix indentation.


>    // TODO getStream same as above but returns an nsIInputStream

seems like getStream would be sufficient.  it could be scriptable even.
we just need to freeze a simple byte-array input stream wrapper class.
we have nsIStringInputStream, but that only really supports ASCII data.

maybe:

    void getStream(in nsIURI	      aURI,
		   out nsIInputStream aStream,
		   out ACString       aContentType,
		   out ACString       aContentCharset,
		   out unsigned long  aContentLength);

why expose the channel?  what can the callback do with the channel anyways?
i suppose the callback might want to access the interface requestor off of the
channel so it can get a prompter to use, etc.  if you do expose the channel,
then
it seems like you don't need to have out params for
content{type,charset,length}
since those can just be set directly on the nsIChannel.


>interface nsISimpleProtocolHandler :  nsISupports
>{
>    /**
>     * Register a callback handler. The callback will be called to handle
>     * uris with the specified scheme.
>     */
>	void registerHandler(in ACString aScheme, in ACString aDescription, in nsISimpleProtocolHandlerCallback aCallback);

maybe you should just force the caller to give you a CID here.	that would
avoid the whole problem of having to invent a CID.

another approach to all of this is to maybe extend nsIOService to search
for simple protocol handlers in much the same was as it searches for full
protocol handlers.  or if we didn't want to declare nsISimpleProtocolHandler
in necko, we could think about extending the mechanism used for unknown
protocols (currently we look for the nsIProtocolHandler registered under the
scheme "default" which is implemented by nsExternalProtocolHandler).

Comment 7

[Adam Lock]

Thanks Darin, I'll fix the nits.

Concerning the TODO, I was thinking of having two versions of getData to
basically allow the client to do one of two things:

a) Return a lump of memory containing the data (easy).
b) Return a stream which could be anything from anywhere (more flexible).

The simple protocol handler would call one and if that returns not implemented
it would call the other. The client would implement the one it wants to use. My
thoughts were having both would give greater choice and the second might be
attractive if they want to feed out some file, or a stream from another request.

Regarding the channel, I put that there so they could query it for any extra
info that was passed with the request. For example, the embedding client might
stuff some extra headers in there during progress notifications and use them
here to determine what to do, or wish to look at some post data etc.

Regarding the CID, I'm not sure it's meaningful for the embedder to supply one
since it's for internal use only, to register the class factory. Perhaps I could
even earmark a range of CIDs and just increment a counter with each new one to
be added.

Comment 8

[Darin Fisher]

>Regarding the CID, I'm not sure it's meaningful for the embedder to supply one
>since it's for internal use only, to register the class factory. Perhaps I 
>could even earmark a range of CIDs and just increment a counter with each new 
>one to be added.

I agree that it is an awkward thing to expose in the API as written.  That's why
I was suggesting changing things so that the IO service might query the
nsISimpleProtocolHandler (or something like it) directly before deferring to the
external protocol handler.  Going this route would completely eliminate the need
to register a dummy nsIProtocolHandler with the component manager.

Comment 9

[Adam Lock]

Attachment: Work in progress, changes to nsIOService.cpp

Picking up an old bug with a patch...

Darin, I'll do your suggestion on this bug. This patch (work in progress)
demonstrates how the nsIOService.cpp could check if there was a simple protocol
service and ask that for an nsIProtocolHandler before looking for external
handlers.

I've made the appropriate changes to the simple protocol handler object
interface, but I've still got to test it

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

hm.. this sounds like bug 234714 would be useful for this