Radha, Here's David's message about proposal: Date: Tue, 25 May 1999 13:54:48 -0700 From: David Matiskella <davidm@netscape.com> Subject: Protocol Dispatching Proposal for 5.0 Heres my memory( with a few embelleshments) of what was proposed at the meeting. Protocol Dispatching Proposal for 5.0 Problem: Figuring out given a URL and a user action, what type of window/application should be responsible for loading the URL. Proposed solution: There would be an AppShellService routine for dispatching URLs. It would get it's information from a registry which would be populated during component registration by a call along the lines of Register( verb, protocol, protocolHandlerCID); where verb - Describes what action the user is performing. Examples would be open, open in new window and save as. protocol - would be the protocol prefix ( "http:", "mailto:", ...) protocolHandlerCID - would be the CID of the object that should be created to actually load the URL. To dispatch the URL, the plan is to have a chain of responsibility so that an app (broswer, bookmarks, mail) gets the first crack at handling a URL before passing it up to the AppShellService routine. There was some discussion about if this chain should be an extension of nsILinkHandler or a separate interface since the nsILinkHandler also has some other responsibilities dealing with style. The routine proposed for dispatching the URL would be along the lines of DoCmd( verb, url, currentWindow, extraArgs ) where verb+ url are the same as above current window is the window where the URL is coming from. It could be null if for the request to load the URL was coming from an external source( Apple event, OLE ). extraArgs is where misc. parameters from the action would occur. An example would be if you dragged a link to the desktop, the extraArgs would be the nsIFileSpec where the file should be saved. Or if you drag a link to another window, extraArgs would be a pointer to that window. Internally in the AppShellService, I would imagine that we would do lookup matching URL and verb ( should there be transformations( something open in window->open in New window) if there isn't an exact match?), which will give us the protocolHandlerCID. The protocolHandler could then be instantiated, and its dispatchURL routine could be called using the provided parameters. This top level registray should be user configurable so that the user could select a 3rd party mail client ( or vice versa ). This could be done by either providing a UI or using the windows registary (win), Internet Config (mac), and whatever service linux provides. The chain of responsibility should prevent dumb things like having the browser load a competing browser to handle http: links from happening. There was also some discussion of how to pick content handlers after the URL is loaded which uses a similiar scheme to map mimetypes to DTDs but I don't remember all the details. One thing I can't remember is who is responsible for setting up the URL dispatching chain? Questions and comments on how badly I mangled everyone's thoughts would be appreciated. The current plan is to get feedback for the next milestone before someone impliments this in m8.

Suppose to meet with nisheeth for his part of the work sometime today. Not sure if this is going to happen.

This feature can not be implemented in its full extent for M8. Reasons being, it depends on some of the netlib notifications which is going to change with NECKO landing. I also understand that Necko is implementing some of the things I need to solve this problem. So, I have to wait until necko lands to take a fresh look at this problem and may be new ways of solving this problem. So, Moving to M10. Making this bug dependant on NEcko landing bug 7232

we should file a bug for the specific area that this bug depends on in necko. removing the dependency on all necko landing bugs 7406

As per discussions last week with don , this has been moved to M11.

*** This bug has been marked as a duplicate of 12580 ***

verified dup...see bug 12580