2010年4月13日17:04 pnormand <pnorm...@igalia.com>: > On Tue, 2010-04-13 at 14:52 -0700, Eric Uhrhane wrote: > > > New topic: Loader. > > > > Things that would be improved by unifying loading between media elements > and the > > rest of webkit: > > Unified resource security model. > > Make application cache work for media. > > Make WebCore cache work for media, better cache balancing by unifying > caching > > with that of the platform MediaEngine cache. > > Make Inspector work better for media. > > Make authentication work [cookies, referrer, http-auth]. > > Easier to add new schemes [data://, file URNs], since it would work > with all > > protocols supported by the loader. > > > > We have another list of requirements for the loader before it could be > used. > > Requirements and drawbacks of unification: > > Need to support non-web protocols such as rtsp. > > May need 2 code paths. > > Need to add byte-range and discontinuous cache support. > > Need to support files > 2GB. > > May be difficult to hook our loader into platform media engine. > > Some media engine's loaders are optimized for media playback > heuristics; we'd > > need to match that behavior. > > Andrew: Threading limitations on resource loaders? > > > > Michael Nordman said something here about using ResourceHandle for this. > He can > > flesh that out, as I didn't follow the discussion. > > > > The GStreamer-based MediaPlayerPrivate has a source element in > WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp that > uses the WebCore infrastructure to load the resources from http(s) > servers and feed the data into the gst pipeline. This way we can reuse > the http session (cookies, referer, ...). > > We can probably use it for data: uris too (we currently have a specific src > element > for this). > > Philippe >
I totally think we should do this instead of implementing resource loading on each port. As a matter of fact, in Chromium we use ResourceHandle directly and provides a layer of buffering and for doing range requests. This allows us to support http:// https:// data://, cookies, referrer, http-auth and even AppCache. Unifying the resource loader also helps pushing a HTTP streaming standard. I think this has great benefits, media resource loading is well within web standard, basically just HTTP range requests, having a common code path that handles buffering, caching and range requests will benefit all. Alpha > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
