Alec, Yeah, I thought about splitting up the interface, but then I realized that many of the functions do make sense on nsIIOService. If you look at the functions provided by nsIProtocolHandler, you'll see that nsIIOService provides basically the same methods as a convenience/ optimization so the caller doesn't have to hit the service manager to find the right protocol handler. This includes:
GetProtocolFlags NewURI NewChannel AllowPort And, leaves off only the |scheme| and |defaultPort| attributes. AllowPort actually does a bit more than just invoke nsIProtocolHandler::AllowPort, but that's besides the point. I think it is also important to provide GetProtocolHandler on nsIIOService since it is something nsIOService must know how to do in order to invoke the right NewURI. Same goes for ExtractScheme. I don't want people hand rolling their own version of ExtractScheme (e.g., strchr(url, ':') just doesn't cut it!). NewFileURI is provided on nsIIOService in order to encourage folks to use this method to map a nsIFile into a nsIURI. That way we can preserve the nsIFile inside the nsIURI implementation. So, I really want that method to be adjacent to NewURI (not that you were suggesting otherwise). That basically just leaves getFileFromURLSpec and getURLSpecFromFile. These do feel somewhat out of place, and I considered moving them elsewhere, but then they do sort of compliment NewFileURI. That is, maybe someone wants to convert a nsIFile into an URL string. If these methods were not on nsIIOService, they'd probably end up calling NewFileURI and then call GetSpec on the result. Not that that's terribly bad, but getURLSpecFromFile is considerably more efficient. Anyways, that's basically why I like having all these methods on the same interface... I think they are reasonably related. Darin Alec Flett wrote: > Darin - > relating to the overall complexity of nsIIOService - what about > splitting it into 2 or 3 interfaces that group relevant actions > together.. just looking at the interface I see a few possiblities that > I might suggest: > > nsIFileURLConverter - getURLSpecFromFile/getFileFromURLSpec > nsIURLParserUtils - extractScheme > nsIProtocolInfo (nsISchemeInfo?) - getProtocolFlags, > getProtocolHandler, allowPort > > what I've done for similar interfaces is to split up the interface, > then define a contractid for an implementation of each interface, and > register the main object (in this case the concrete nsIOService) > under each of these contractids - that way, I can later split up the > object if I want without affecting the callers, and I can freeze one > specific interface without affecting callers on the other interfaces. > > Alec > > Doug Turner wrote: > >> this may effect aol clients. >> ------------------------------------------------------------------------ >> >> Subject: >> FYI: upcoming nsIIOService API changes >> From: >> [EMAIL PROTECTED] >> Date: >> Wed, 31 Jul 2002 12:46:06 -0700 >> To: >> [EMAIL PROTECTED] >> >> >> I'm planning to rev nsIIOService in preparation for marking it frozen >> by Mozilla 1.2. See http://bugzilla.mozilla.org/show_bug.cgi?id=157131. >> >> Unfortunately, nsIIOService has been the dumping ground in necko for >> miscellaneous functions. I'm hoping to eliminate some of the cruft. >> >> I'm planning on dropping the following methods: >> >> GetParserForScheme - this function is unused outside necko, but >> more importantly it exposes nsIURLParser, >> which is more or less a necko implementation >> detail. not all protocols register a >> nsIURLParser, and as a result the default >> nsIURLParser implementation is often used. >> the default nsIURLParser implementation is >> therefore not guaranteed compatible with the >> nsIURI implementation returned from >> nsIProtocolHandler::NewURI. Eliminating this >> API therefore closes the potential security >> risk of this API (e.g., two components may >> parse the same URL string differently leading >> to broken security checks). >> >> ExtractUrlPart - this function is commonly used to >> "efficiently" parse an arbitrary URL string >> without the overhead of calling >> nsIProtocolHandler::NewURI. this function >> depends on the result returned from >> GetParserForScheme and therefore suffers the >> same potential security risk. the performance >> benefits (i'll assert that these are minor) do >> not outweigh the potential security risk >> levied by this interface on unsuspecting >> components (especially those developed >> externally without the review of mozilla >> developers well aware of such security >> issues). >> >> ResolveRelativePath - this is only used internally by necko to >> implement the JAR protocol handler. there is >> no need to expose this utility function on >> nsIIOService. >> >> I'm also proposing a change to this method: >> >> void initFileFromURLSpec(in nsIFile file, in AUTF8String url); >> >> This method should be modified to return a nsIFile instead of >> expecting one to be preallocated by the caller. This interface >> breaks the abstraction of the nsIFile interface since it requires a >> caller to know apriori that the URL corresponds to a local file. >> dougt suggested the following signature instead: >> >> nsIFile getFileFromURLSpec(in AUTF8String url); >> >> A little LXR'ing should confirm that this isn't going to cause too >> much trouble for existing mozilla components. >> >> I'll also be rev'ing the IID, CID, and ContractID along with these >> changes. That should minimize crashes resulting from plugins and >> other external components leveraging the current "unfrozen" >> nsIIOService interface. They just won't work ;-) >> >> Darin >>
