Closed Bug 14928 Opened 20 years ago Closed 20 years ago
[DOGFOOD] [PORKJOCKEY]URL Dispatching Part II
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.
*** Bug 16611 has been marked as a duplicate of this bug. ***
anyone has a status on this bug? where are we on URL dispatching?
*** Bug 17085 has been marked as a duplicate of this bug. ***
Summary: URL Dispatching Part II → [DOGFOOD] URL Dispatching Part II
Target Milestone: M12
Summary: [DOGFOOD] URL Dispatching Part II → [DOGFOOD] [PORKJOCKEY]URL Dispatching Part II
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.
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. ***
*** Bug 12580 has been marked as a duplicate of this bug. ***
*** 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.
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. ***
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
You need to log in before you can comment on or make changes to this bug.