[Bug 25319] [imports]: Want some kind of imperative API

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319

Dan McDougall <riskable@youknowwhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |riskable@youknowwhat.com

--- Comment #1 from Dan McDougall <riskable@youknowwhat.com> ---
I just wanted to add that this will be a very important feature for
applications that wish to cache web components in browser storage (e.g.
IndexedDB) or load web components via a WebSocket connection.  It also allows
for making changes to web components (say, changing the element name or
inserting additional stylesheets) before they get loaded which would be a
killer feature.

My Use Case:

Personally, I just need a mechanism that would allow me to load a web component
via a WebSocket without requiring a separate GET request.  My application (Gate
One) gets embedded into other web pages directly (no iframe) and it
loads/synchronizes all of its assets (JS, CSS, and now HTML templates) over a
single WebSocket connection.  It caches assets via IndexedDB (with localStorage
fallback) and only re-downloads them when a file gets changed on the server. 
That asset synchronization works incredibly well:  It's much faster than
individual GET requests and more flexible and efficient than concatenation. 
However, there's no way for me to take advantage of web components (currently)
using that same mechanism.  If I could download a web component over the
WebSocket and load it into the page somehow that would solve the problem.

Even if I could provide a data::URI as the 'href' attribute to a link tag that
would work.  I'd just create the data::URI from the cached web component
on-the-fly so the inefficiency of base64 encoding would be moot.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 8 September 2014 14:57:44 UTC