8628 - [FEATURE] URL dispatching

Status: VERIFIED DUPLICATE of bug 12580

(SeaMonkey :: UI Design, defect, P1)

Description

[don]

Radha,

Here's David's message about proposal:

Date: Tue, 25 May 1999 13:54:48 -0700
From: David Matiskella <[e-mail]>
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.

Comment 1

[Radha on family leave (not reading bugmail)]

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

Comment 2

[Radha on family leave (not reading bugmail)]

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

Comment 3

[chris hofmann]

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

Comment 4

[Radha on family leave (not reading bugmail)]

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

Comment 5

[Radha on family leave (not reading bugmail)]

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

Comment 6

[Jay Patel [:jay]]

verified dup...see bug 12580