Confirmed users
2,615
edits
User:Dmose:Fx-Docs:ContentTypeProcessing: Difference between revisions
Jump to navigation
Jump to search
User:Dmose:Fx-Docs:ContentTypeProcessing (view source)
Revision as of 00:53, 7 March 2007
, 7 March 2007no edit summary
No edit summary |
No edit summary |
||
| Line 7: | Line 7: | ||
= Overview = | = Overview = | ||
Streamline and extend the handling of | Streamline and extend the handling of typed content on the web. | ||
== Motivation == | == Motivation == | ||
| Line 20: | Line 20: | ||
** allow a website to render an Excel spreadsheet into HTML in an iframe | ** allow a website to render an Excel spreadsheet into HTML in an iframe | ||
** hand off a mailto: URL to a web mail app for composition | ** hand off a mailto: URL to a web mail app for composition | ||
** display a news: URL using Google Groups | |||
== Requirements == | == Requirements == | ||
| Line 39: | Line 40: | ||
== API Changes == | == API Changes == | ||
* navigator.registerContentHandler() will actually use registrations for non-feed types rather than dropping them on the floor | |||
* navigator.registerProtocolHandler() will be implemented | |||
* probable internal API changes related to both of the above | |||
* possible internal API changes related to streaming content handling | |||
* possible internal API changes related to minimizing database duplication | |||
== Extensibility == | == Extensibility == | ||
register{Content,Protocol}Handler are by definition extensibility features. If one wanted to implement a handler in add-on chrome, that should theoretically Just Work, but if we care about this case, we should explicitly say so to ensure appropriate testing. To some degree, everything else we're doing here is also about enhancing and streamlining the extensibility experience. | |||
== Customization == | == Customization == | ||
Similarly, this set of features is entirely related to the ability for users to customize their web experience. | |||
== Performance == | == Performance == | ||
The only performance change that I anticipate is that web-based content handlers are almost certain to be slower than local ones. I suspect that any overhead incurred by the browser here is likely to be lost in the noise of network latency. That said, it would be good to do some profiling to ensure that this is the case. | |||
== Reliability/Stability == | == Reliability/Stability == | ||
' | We'll need to figure out what the failure mode should be when content is handed off to a website handler that is down. This is particularly interesting in the case of dynamically generated content (e.g. receipts). | ||
== Security == | == Security == | ||
' | The content-handler stuff will definitely need a security review. The [http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers WHATWG Web Apps spec] discusses some of the stuff we'll need to think about there. We also need to ensure that any changes made w.r.t. how we interact with OS definitions of content-handlers don't introduce new security flaws. | ||
== Privacy == | == Privacy == | ||
Any content that a user chooses to have handled by a web app will (or at least could) be disclosed to the operator of the web application. | |||
== Global Audience == | == Global Audience == | ||
Nothing unusual anticipated. | |||
== Web Compatibility == | == Web Compatibility == | ||
We will likely be the first extensive implementor of the register{Content,ProtocolHandler} pieces. This may merit some evangelism to key web application implementors. | |||
== Other == | == Other == | ||
| Line 70: | Line 75: | ||
= Discussion & Implications = | = Discussion & Implications = | ||
One of the interesting things that will need to be addressed | |||
== Caveats / What We've Tried Before == | == Caveats / What We've Tried Before == | ||
''links to previous design documents, discussions, etc.'' | ''links to previous design documents, discussions, etc.'' | ||
== References == | == References == | ||
The [https://addons.mozilla.org/firefox/4498/ MIME Edit] addon has some example UI that is more complete than our current UI, though not particularly friendly to non-technical users. | |||
[http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers WhatWG Web Applications spec] | |||