14928 - [DOGFOOD] [PORKJOCKEY]URL Dispatching Part II

Status: CLOSED FIXED

(Core :: Networking, defect, P3)

Description

[Scott MacGregor]

Part I is covered in Bug #14927. The second part to url dispatching involves
dispatching based on mime content type.

For instance, you click on an http url in the browser and after we start
downloading the file, we discover that it is an mp3. We obviously don't want to
dump the mp3 contents to the screen, instead we need to redirect the output to
an application which can handle the content type.

A couple things need to happen here:

1) We need to separate out the notion of opening and begining to read data out
of a channel. Both of these operations are represented by calling AsyncRead. We
need to allow you to open a channel. When a channel is open but not marked for
reading, the channel doesn't forward incoming data through ODA calls. It figures
out the content type (which for http may be in a header) and calls back to the
caller with the content type. The caller can than pass the channel on to someone
which does know about this content type and they can call AsyncRead to actually
start reading data.

For instance, if the content type is mp3, we might have a helper class which
just spools the mp3 file to disk and then invokes the appropriate plugin for
mp3.

2) We also need mechanism for discovering who can handle the new incoming
content type.

3) How do we map platform specific plugins into mozilla. i.e. the Mac uses
internet config, windows uses ??? and linux uses...well nothing really =). We
almost want a generic interface through which we discover these mime type to
helper application mappings. Then we can use a text file in the early stages but
eventually can have platform specific implementations which use the appropriate
platform tools (like internet config) to figure things out.

Comment 1

[Scott MacGregor]

I forgot to add Bill and Radha when I filed this bug over the weekend.

Comment 2

[Judson Valeski]

The "download file of unknown type" dialog is an example of where we need to
employ this MIME-based dispatching.

Pam Nunn, Rick Gessner and I have been talking about a data scanning api that
scans the first X bytes of a buffer and takes a data based guess at what the
content type is. Pam has code that does this in image lib, and gessner has some
in the DTD code.

I discussed a home for this api (and implementation) with warren and concluded
two things:

1. A sensible home for the api and impl would be off of the
nsIStreamConverterService.
2. Streams need to be peekable.

Comment 3

[Phil Peterson]

*** Bug 16611 has been marked as a duplicate of this bug. ***

Comment 4

[Cathleen]

anyone has a status on this bug?
where are we on URL dispatching?

Comment 5

[Scott MacGregor]

*** Bug 17085 has been marked as a duplicate of this bug. ***

Comment 6

[leger]

Important porkjockey work, but not needed for dogfood.  PDT-

Comment 7

[Warren Harris]

What -- you don't want to click on a link in mailnews and go to the browser for
dogfood?

Comment 8

[Chris McAfee]

I agree with warren, mail would be much more useable with link-clicking
working.

Comment 9

[Scott MacGregor]

I'm going to be landing the first stage for uri dispatching in the next day or
two.

The basic uri loading logic lives in mozilla\uriloader. I've grafted some
changes on top of the existing docloader and webshell to use the new uri loader
when loading urls.

Currently dispatching works between open windows (I haven't written bootstrap
code to bring up a new window yet). i.e. if you are reading mail and you click
on a link that has content the browser can handle, the load is re-directed to
the open browser window. And vice versa.

Things that won't work when I land stage one:
1)retargeting. retargeting isn't finished yet for the protocols so we don't
switch the load group and change the event sink getter for the channel when we
redirect the output.  So you won't see progress switched to the new window and
hitting cancel in the new window won't cancel the load.
2) i'm having trouble getting forward and back buttons to work when uri loading
is enabled
3) in the browser window, when redirecting a url to that window, the <br>browser
title isn't hooked up.
4) platform specific content handlers aren't online yet.

To make the transition to the new uri loader incremental and to minimize
risk of breaking the world,I've added a pref to the QA menu which will allow you
to turn on uri dispatching for the protocols which support it. This should make
it easy for people to try it out if they want.

Anyway, that's just a small update and taste of things to come.

Comment 10

[Ben Bucksch (:BenB)]

*** Bug 19269 has been marked as a duplicate of this bug. ***

Comment 11

[Phil Peterson]

*** Bug 12580 has been marked as a duplicate of this bug. ***

Comment 12

[Phil Peterson]

*** Bug 10233 has been marked as a duplicate of this bug. ***

Comment 13

[Scott MacGregor]

I'm flipping the switch to turn uri loading on tonight. When I turn the
preference on, all urls run through the webshell will now be re-routed to the
uriloader.

Comment 14

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 15

[Phil Peterson]

Scott, can we close this bug and file new ones as necessary?

Comment 16

[Phil Peterson]

*** Bug 7406 has been marked as a duplicate of this bug. ***

Comment 17

[Scott MacGregor]

There isn't any outstanding issues in this bug that are for M13. Any problems
are already described in separate dispatching bugs marked m13.

Comment 18

[Phil Peterson]

Scott says everything in here is covered more specifically in other bugs.
Marking fixed.

Comment 19

[Tom Everingham]

closing - development related issues