Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

adding scheme to nsIHandlerInfo

14 views
Skip to first unread message

Myk Melez

unread,
Jul 6, 2007, 10:37:30 PM7/6/07
to Dan Mosedale, Shawn Wilsher, Christian Biesinger
At the moment there's no way to get the scheme from an nsIHandlerInfo
object for a protocol. dmose and I were talking on IRC that it'd make
sense to add that, perhaps via a "type" property that contains the
scheme for protocol handlers and the MIME type for MIME type handlers.

I think I'm going to need the scheme sooner or later as I add support
for protocols to Firefox's configuration UI, so I'm looking into adding
it, but it's not clear how best to do it.

nsIHandlerInfo objects are instances of nsMIMEInfoImpl. They get
created via a constructor that takes a string representing the MIME type
[1]. For protocol handlers, we don't pass that string [2].

We could make the constructors take a generic type instead of a MIME
type (reflecting the former into the latter for backwards
compatibility), but right now the absence of a MIME type is the only way
to differentiate a protocol handler from a MIME type handler.

Alternately, we could add a generic "type" property that we set after
instantiating the nsMIMEInfoImpl. But then we'd have to update all the
existing instantiators and subclasses of nsMIMETypeImpl to support that
property.

Or we could just add a "scheme" property that we only set for protocol
handlers and punt on a generic "type" property for the moment.

Thoughts? Other options?

-myk

[1]
http://mxr.mozilla.org/mozilla/source/uriloader/exthandler/nsMIMEInfoImpl.cpp#48
[2]
http://mxr.mozilla.org/mozilla/source/uriloader/exthandler/nsExternalHelperAppService.cpp#1479

Christian Biesinger

unread,
Jul 7, 2007, 8:24:31 AM7/7/07
to Myk Melez, dev-pl...@lists.mozilla.org, Shawn Wilsher, Dan Mosedale
Myk Melez wrote:
> We could make the constructors take a generic type instead of a MIME
> type (reflecting the former into the latter for backwards
> compatibility), but right now the absence of a MIME type is the only way
> to differentiate a protocol handler from a MIME type handler.
[...]

> Or we could just add a "scheme" property that we only set for protocol
> handlers and punt on a generic "type" property for the moment.

Protocol handlers should not have the MIME type property IMO... And if
you do the second suggestion, content handlers should not have the
scheme property, because it doesn't make sense for them. The two should
be differentiated by not allowing to QI protocol handlers to nsIMIMEInfo.

Anyway, that said, I like both of those suggestions.

The other one (setting the type after instantiation) doesn't seem to
have any advantages.


--
All the world's a stage,
And all the men and women merely players:
They have their exits and their entrances;
And one man in his time plays many parts, [...] --W. Shakespeare

Dan Mosedale

unread,
Jul 9, 2007, 9:43:07 PM7/9/07
to
Christian Biesinger wrote:
> Myk Melez wrote:
>> We could make the constructors take a generic type instead of a MIME
>> type (reflecting the former into the latter for backwards
>> compatibility), but right now the absence of a MIME type is the only
>> way to differentiate a protocol handler from a MIME type handler.
> [...]
>> Or we could just add a "scheme" property that we only set for protocol
>> handlers and punt on a generic "type" property for the moment.
>
> Protocol handlers should not have the MIME type property IMO... And if
> you do the second suggestion, content handlers should not have the
> scheme property, because it doesn't make sense for them. The two should
> be differentiated by not allowing to QI protocol handlers to nsIMIMEInfo.
>
> Anyway, that said, I like both of those suggestions.

I like the first suggestion: have a generic "type" or "kind" or
whatever, and fix up QI to do the right thing.

Dan

0 new messages