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
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
I like the first suggestion: have a generic "type" or "kind" or
whatever, and fix up QI to do the right thing.
Dan