Closed Bug 14928 Opened 20 years ago Closed 20 years ago

[DOGFOOD] [PORKJOCKEY]URL Dispatching Part II

Categories

(Core :: Networking, defect, P3, blocker)

All
Windows NT
defect

Tracking

()

CLOSED FIXED

People

(Reporter: mscott, Assigned: mscott)

References

Details

(Whiteboard: [PDT-])

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.
I forgot to add Bill and Radha when I filed this bug over the weekend.
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.
Blocks: 15162
Blocks: 12580
Blocks: 11281
Blocks: 16654
*** Bug 16611 has been marked as a duplicate of this bug. ***
Blocks: 16950
Blocks: 2652
Blocks: 5247
Blocks: 10233
Severity: normal → blocker
anyone has a status on this bug?
where are we on URL dispatching?
*** Bug 17085 has been marked as a duplicate of this bug. ***
Blocks: 10892
Blocks: 17432
Blocks: 17907
Blocks: 18412, 18413
No longer blocks: 18412, 18413, 18414, 18415, 18416, 18417, 18418
Depends on: 18412, 18413, 18414, 18415, 18416, 18417, 18418
Summary: URL Dispatching Part II → [DOGFOOD] URL Dispatching Part II
Target Milestone: M12
Blocks: 18471
Summary: [DOGFOOD] URL Dispatching Part II → [DOGFOOD] [PORKJOCKEY]URL Dispatching Part II
Whiteboard: [PDT-]
Important porkjockey work, but not needed for dogfood.  PDT-
What -- you don't want to click on a link in mailnews and go to the browser for
dogfood?
I agree with warren, mail would be much more useable with link-clicking
working.
Blocks: 18951
Status: NEW → ASSIGNED
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.
*** Bug 19269 has been marked as a duplicate of this bug. ***
Blocks: 20203
*** Bug 12580 has been marked as a duplicate of this bug. ***
No longer blocks: 10233
*** Bug 10233 has been marked as a duplicate of this bug. ***
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.
Blocks: 20870
Target Milestone: M12 → M13
Blocks: 21564
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
Scott, can we close this bug and file new ones as necessary?
*** Bug 7406 has been marked as a duplicate of this bug. ***
Target Milestone: M13 → M14
There isn't any outstanding issues in this bug that are for M13. Any problems
are already described in separate dispatching bugs marked m13.
Scott says everything in here is covered more specifically in other bugs.
Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
closing - development related issues
Status: RESOLVED → CLOSED
No longer blocks: 17432
No longer blocks: 17907
No longer blocks: 18471
No longer blocks: 18951
No longer blocks: 20203
No longer blocks: 20870
No longer blocks: 21564
You need to log in before you can comment on or make changes to this bug.