It seems unnecessary to have two distinct objects to represent the same thing. Now that nsIWebHandlerApp inherits from nsIHandlerApp, we should make nsIWebContentHandlerInfo inherit from nsIWebHandlerApp or perhaps just be replaced by it.

Note that in my latest patch for bug 377784 I get us partway there by making nsIWebContentHandlerInfo inherit from nsIHandlerApp (this avoided hackiness in some code for the new Applications prefpane). Since nsIWebContentHandlerInfo already has both name and equals() (the latter of which bug 393492 adds to nsIHandlerInfo), this change was as simple as removing those two attributes from nsIWebContentHandlerInfo and then making that interface inherit from nsIHandlerApp. But I did also modify the implementation of equals() in WebContentConverter.js's ServiceInfo prototype to conform to the implementations added in bug 393492.

So, this actually looks pretty simple, but I'm looking for a reality check. nsIWebContentHandlerInfo can die as long as we add the following attribute and method to nsIWebHandlerApp: type (represents protocol or mime type) AString getHandlerURI[ForURI](in nsIURI aURI); (obtains the correct uri for the handler given a source uri) this make sense?

(In reply to comment #2) > So, this actually looks pretty simple, but I'm looking for a reality check. > > nsIWebContentHandlerInfo can die as long as we add the following attribute and > method to nsIWebHandlerApp: > type > (represents protocol or mime type) > AString getHandlerURI[ForURI](in nsIURI aURI); > (obtains the correct uri for the handler given a source uri) > > this make sense? I think that's correct, but I'm not sure it makes sense. getHandlerURI seems innocuous enough (and it should be easy enough to make nsIWebHandlerApp consumers switch to using that method instead of their own custom %s-replacement routines), but should type really be a property of nsIWebHandlerApp? That seems limiting given that web handler apps might be able to handle multiple types.

Well, I can actually see the need to determine what types of protocols that app supports. But really, given how our system works, I don't think it matters much if it supports more than one type - we'll still get an app for each type out of it (I hope that makes sense).