Re: ZIP archive API?
On Mon, May 6, 2013 at 6:36 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, May 6, 2013 at 8:01 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, May 6, 2013 at 5:15 PM, Glenn Maynard gl...@zewt.org wrote: I'm not aware of any optimized inflate implementation in JS to compare against, and it's a complex algorithm, so nobody is likely to jump forward to spend a lot of time implementing and heavily optimizing it just to show how slow it is. I've seen an implementation around somewhere, but it didn't use typed arrays so it would need a lot of reworking to have any meaning. Likewise, I don't see any browser vendor jumping ahead and doing both the work to implement a library *and* and API to compare the two. Sorry, this didn't make sense. What library *and* API are you talking about? To compare what? A library for zip compression/decompression and an API for zip compression/decompression. So that we can compare the performance of the two. Every browser already has native inflate, though. This is unfortunately not a terribly strong argument. Exposing that implementation through a DOM API requires a fairly large amount of work. Not to add maintaining that over the years. You're arguing for allowing accessing files inside ZIPs by URL, which means you're going to have to do the work anyway, since you'd be able to create a blob URL, reference a file inside it using XHR, and get a Blob as a result. This is a small subset of that. No, the work to write and maintain an API for ZIP compress/decompression is pretty orthogonal, implementation-wise, to a protocol handler for ZIP decompression. Look, the fact that we need use cases should not be surprising to people on this mailing list. And I know that it's not surprising to you. One of the heavy arguments that has been brought up for a ZIP archive API has been that it provides better performance. That's a claim that needs to be backed up by numbers in order to carry any weight. The argument that you're bringing up is it's easy to implement (because you already have an zip library) is also a very weak argument. Until we get stronger arguments for an archive API, I'd be happy to see a proposal for a protocol handler. / Jonas
Re: Blob URLs | autoRevoke, defaults, and resolutions
On Mon, May 6, 2013 at 5:57 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 6, 2013 at 5:45 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, May 6, 2013 at 4:28 PM, Anne van Kesteren ann...@annevk.nl wrote: Okay. So that fails for XMLHttpRequest :-( What do you mean? Those are the steps we take for XHR requests too. So e.g. open() needs to do URL parsing (per XHR spec), send() would cause CSP to fail (per CSP spec), send() also does the fetch (per XHR spec). Overall it seems like a different model from the other APIs, but maybe I'm missing something? The only thing that's different about XHR is that the first step in my list lives in one function, and the other steps live in another function. Doesn't seem to have any effect on the discussions here other than that we'd need to define which of the two functions does the step which grabs a reference to the Blob. / Jonas
Re: ZIP archive API?
On Tue, May 7, 2013 at 8:09 AM, Jonas Sicking jo...@sicking.cc wrote: You're arguing for allowing accessing files inside ZIPs by URL, which means you're going to have to do the work anyway, since you'd be able to create a blob URL, reference a file inside it using XHR, and get a Blob as a result. This is a small subset of that. No, the work to write and maintain an API for ZIP compress/decompression is pretty orthogonal, implementation-wise, to a protocol handler for ZIP decompression. In order to implement zip you would use one of the ready made libraries supporting it, such as libzip (http://www.nih.at/libzip/index.html), minizip (http://www.winimage.com/zLibDll/minizip.html), Both libraries (and any other library you might encounter) already defines an API and an implementation. In order to support ZIP URLs you would use the API. In order to support a JS zip API, you would expose the API. These are not orthogonal, they are correlated.
Re: Proposal for a DOM L3 Events Telecon
Hello, sorry for the big delay due to my business trip and holiday week of Japan. I'm available on either schedule. When I join the telecon, how can I join it? Skype or something? And please note that I cannot speak and listen to English well. But I'd like to join it. Thank you. On 2013/04/30 21:46, Gary Kačmarčík (Кошмарчик) wrote: On Mon, Apr 29, 2013 at 12:59 PM, Travis Leithead travis.leith...@microsoft.com mailto:travis.leith...@microsoft.com wrote: I’d like to propose we start a call to begin to work toward resolving the final bugs in the spec and for other business related to getting DOM L3 Events to CR. On the call we can workout what subsequent meetings we should also arrange. __ __ Does next Tuesday (May 7^th ), at 11 am PST work your you? Note that 11am PDT = 3am JST. If Masayuki is interested in joining, we should pick a late afternoon PDT time: 4pm PDT (Tue) = 8am JST (Wed) 5pm PDT (Tue) = 9am JST (Wed) -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan.
Re: Re: [XHR] test nitpicks: MIME type / charset requirements
It seems strange the spec would require a case-sensitive value for Content-Type in certain circumstances. There's only two things that seem to work well over a long period of time given multiple implementations and developers coding toward the dominant implementation (this describes the web). 1. Require the same from everyone. 2. Require randomness. We're discussing the case of a MIME type parameter sent from a client to a server, the question is basically where to draw the line between what we spec and what we leave up to the implementation. Currently, according to the spec the charset param is expected to be sent in lower case if the charset the JS sets matches (case insensitively!) the charset the implementation sends data in, and the JS used lower case (i.e. text/plain;charset=utf-8 will send charset=utf-8), in upper case if the implementation rewrites any charset parameter (text/plain;charset=foo = text/plain;charset=UTF-8 and perhaps least expected text/plain;charset=utf-8;charset=foo = text/plain;charset=UTF-8;charset=UTF-8). So per the spec itself the value may sometimes be lower cased, sometimes upper cased, and it may sometimes be transformed to upper case even if it was originally given in lower case. We have no evidence that servers require or prefer a certain case. Servers (like Apache, IIS and Nginx) are generally written by professionals who understand case insensitivity. Server-side scripting, on the other hand, is not necessarily of high quality and might end up requiring a certain case. If such scripts exist, and if it's not documented what case is expected, we will end up with one of those small gotchas that are so harmful to cross-implementation compat. (On the other hand, if we already have a state where a variety of input is accepted and narrow down what is considered legal, content may well follow - this risks creating one of those backwards incompatibilities that annoy users with older devices and versions. IMO as spec authors we should also keep backwards compatibility in mind and not diverge from existing implementations unless we have good reasons.) TL;DR: I'm not aware of evidence that spec'ing this is required for compat, I do buy the argument that precision might cause better future compat, I'm however concerned about back compat and find it surprising that a strictly spec'ed implementation detail will sometimes transform the case the script actually used. 'HR Anything else is likely to lead some subset of developers to depend on certain things they really should not depend on and will force everyone to match the conventions of what they depend on (if you're in bad luck you'll get mutual exclusive dependencies; the web has those too). E.g. the ordering of the members of the canvas element is one such thing (trivial bad luck example is User-Agent). -- http://annevankesteren.nl/ -- Hallvord R. M. Steen Core tester, Opera Software
Rough summary of minutes from the face to face
Hi, in line with the last item on this list, I committed to make a rough summary of the meeting available to go with the raw minutes. The idea is that people who aren't in the group and weren't there can actually understand what the minutes mean. So here it is. Minutes for Thursday[2] and Friday[2] are available Notes on the topics listed in the minutes: Thursday =Dashboard / PubStatus Webapps maintains a wiki page[4] with the latest knowledge about the specs the group is working on. =App Manifest This is a manifest for packaged (i.e. an installable zip) or hosted (something like pages with an appcache manifest) apps, that provides metadata, an icon, etc. It will be moved from the Sysapps group to the web apps group, who already have it as an explicit charter deliverable. There is a comparison chart[5] of Manifest formats available (but not 100% correct - I believe contributions are welcome. =AppCache There are two initial proposals for fixing it, one from Mozilla[6], and one expected from Google based on Navigation Controller[7]. A key question is whether to have a declarative format (Jonas' proposal has a JSON format that is more or less declarative, Navigation Controller is just script). NB Since the meeting we have started to collect use cases[8] in our Wiki =Indexed DB Hopefully version 1 will be finished in a few months. It seems the last point of disagreement was resolved at the meeting, so we expect a new draft in a couple of weeks that will be more or less the final one. =DOM3 Events - Status Update Keyboard events are known to be difficult to standardise. They don't have enough tests to be confident that they have this part right, and want more. Maybe they will be ready some time around the end of the year. =Web Components There are now 4 specifications that are being developed to allow the creation of custom elements in HTML (and XHTML). The work is led by Dmitry Glazkov from Google. There was an introduction to the various specs, where they fit and where they are up to. =Web Components Security Model, CORS, CSP This was a brief discussion with the Web App Security working group, just describing basic things and meeting the people. =IME This specification is meant to allow use cases including writing a custom IME to replace the system one (like what we do for translate), to make sure that it is easier to interact cleanly with IME when doing something like suggest, etc. There was a joint meeting with an accessibility group, but they were more concerned about building editors (which is very hard) than actual IME (which is moderately hard, unless you can't interact with the native one which makes it horribly hard). =File API Mozilla has a new proposal[9] (as of the morning of the meeting). FileAPI has a few outstanding issues, and is likely to try and ship rather than updating to use futures, ... =WebIDL This probably only matters for people writing specs. WebIDL level 1 is likely to be finished in a few months, with level 2 work ongoing. Friday =Testing, Move to Github The Web needs more tests. There are occasional Test The Web Forward events where people make them. W3C is moving its test infrastructure to use a single github repository for everything. =Progress Events These are used by XHR, the img element, and the Sysapps messaging API. The spec should be finalised in summer =XMLHttpRequest There will be a level 1 specification that describes the interoperable bits, to be finalized this year. Work will continue on level 2, with CORS, authentication, etc, aiming to be done by late 2014. =Coordination (TC39) There has been a discussion asking for more coordination with TC39 for things like making sure that when new APIs are developed at W3C (e.g. in Webapps) there is a notice to them so they can give an early review on things like whether the API looks like normal Javascript, not something mostly designed as if it were in C++ or some other language. The conclusion was Please do more coordination. [1] http://www.w3.org/wiki/Webapps/April2013Meeting [2] http://www.w3.org/2013/04/25-webapps-minutes.html [3] http://www.w3.org/2013/04/26-webapps-minutes.html [4] http://www.w3.org/2008/webapps/wiki/PubStatus [5] http://www.w3.org/community/webappstore/wiki/Manifest [6] http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0977.html [7] https://github.com/slightlyoff/NavigationController [8] http://www.w3.org/wiki/Webapps/AppCacheUseCases [9] http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0382.html I'm interested in whether this was a useful exercise, by the way. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Manifest, Re: Rough summary of minutes from the face to face
On Tuesday, May 7, 2013 at 11:16 AM, Charles McCathie Nevile wrote: =App Manifest This is a manifest for packaged (i.e. an installable zip) or hosted (something like pages with an appcache manifest) apps, that provides metadata, an icon, etc. It will be moved from the Sysapps group to the web apps group, who already have it as an explicit charter deliverable. There is a comparison chart[5] of Manifest formats available (but not 100% correct - I believe contributions are welcome. Just a note that when it's moved to WebApps it will not contain any Zip file related stuff. The packaged app side of things will remain at SysApps. The Editor's Draft can be accessed at: http://www.w3.org/2012/sysapps/manifest/ Or: http://manifest.sysapps.org/ You can access the GitHub repo here: https://github.com/sysapps/manifest And you can file bugs here: https://github.com/sysapps/manifest/issues Pull Requests welcomed! Please review the document and file bugs on Github. Kind regards, Marcos
Re: [XHR] test nitpicks: MIME type / charset requirements
On 2013-05-07 00:44, Julian Aubourg wrote: Hey Anne, I don't quite get why you're saying HTTP is irrelevant. As an example, regarding the content-type /request /header, the XHR spec clearly states: If a |Content-Type| header is in author request headers http://www.w3.org/TR/XMLHttpRequest/#author-request-headers and its value is a valid MIME type http://dev.w3.org/html5/spec/infrastructure.html#valid-mime-type that has a |charset| parameter whose value is not a case-insensitive match for encoding, and encoding is not null, set all the|charset| parameters of that |Content-Type| header to encoding. So, at least, the encoding in the request content-type is clearly stated as being case-insensitive. BTW, Valid MIME type leads to (HTML 5.1): A string is a valid MIME type if it matches the |media-type| rule defined in section 3.7 Media Types of RFC 2616. In particular, a valid MIME type http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#valid-mime-type may include MIME type parameters. [HTTP] http://www.w3.org/html/wg/drafts/html/master/iana.html#refsHTTP Of course, nothing is explicitely specified regarding the /response /content-type, because it is implicitely covered by HTTP (seeing as the value is generated outside of the client -- except when using overrideMimeType). It's usage as defined by the XHR spec is irrelevant to the fact it is to be considered case-insensitively : any software or hardware along the network path is perfectly entitled to change the case of the Content-Type header because HTTP clearly states case does not matter. So, testing for a response Content-Type case-sensitively is /not /correct. Things are less clear to me when it comes to white spaces. I find HTTP quite evasive on the matter. ... RFC 2616 is pretty clear if and only if you understand how implied linear whitespace works in it's version of ABNF. In HTTPbis, we removed implied whitespace rules, so you may want to look at http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#media.type instead (note that this is past WGLC and will be in IETF Last Call soonish). Best regards, Julian
Re: [XHR] test nitpicks: MIME type / charset requirements
On 2013-05-07 11:39, Hallvord Reiar Michaelsen Steen wrote: It seems strange the spec would require a case-sensitive value for Content-Type in certain circumstances. There's only two things that seem to work well over a long period of time given multiple implementations and developers coding toward the dominant implementation (this describes the web). 1. Require the same from everyone. 2. Require randomness. We're discussing the case of a MIME type parameter sent from a client to a server, the question is basically where to draw the line between what we spec and what we leave up to the implementation. Currently, according to the spec the charset param is expected to be sent in lower case if the charset the JS sets matches (case insensitively!) the charset the implementation sends data in, and the JS used lower case (i.e. text/plain;charset=utf-8 will send charset=utf-8), in upper case if the implementation rewrites any charset parameter (text/plain;charset=foo = text/plain;charset=UTF-8 and perhaps least expected text/plain;charset=utf-8;charset=foo = text/plain;charset=UTF-8;charset=UTF-8). So per the spec itself the value may sometimes be lower cased, sometimes upper cased, and it may sometimes be transformed to upper case even if it was originally given in lower case. We have no evidence that servers require or prefer a certain case. Servers (like Apache, IIS and Nginx) are generally written by professionals who understand case insensitivity. Server-side scripting, on the other hand, is not necessarily of high quality and might end up requiring a certain case. If such scripts exist, and if it's not documented what case is expected, we will end up with one of those small gotchas that are so harmful to cross-implementation compat. (On the other hand, if we already have a state where a variety of input is accepted and narrow down what is considered legal, content may well follow - this risks creating one of those backwards incompatibilities that annoy users with older devices and versions. IMO as spec authors we should also keep backwards compatibility in mind and not diverge from existing implementations unless we have good reasons.) TL;DR: I'm not aware of evidence that spec'ing this is required for compat, I do buy the argument that precision might cause better future compat, I'm however concerned about back compat and find it surprising that a strictly spec'ed implementation detail will sometimes transform the case the script actually used. ... Indeed. See also http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0955.html about the requirement to rewrite charset parameters in-place, and - slightly related - https://www.w3.org/Bugs/Public/show_bug.cgi?id=15312 about the requirement to lowercase header field names in CORS. Best regards, Julian
Re: Blob URLs | autoRevoke, defaults, and resolutions
On Mon, May 6, 2013 at 10:52 PM, Eric U er...@google.com wrote: I'm not really sure what you're saying, here. If you want an URL to expire or otherwise be revoked, no, you can't use it multiple times after that. If you want it to work multiple times, don't revoke it or don't set oneTimeOnly. No, I'm saying that APIs *internally* may perform multiple fetches, such as if you load an API into video and the user performs multiple pauses and seeks. This should be completely transparent to script. Similarly, if you load blob URLs into srcset, the fact that srcset might load or reload the images any number of times in the future due to changes to the environment should be completely transparent to script. There are lots of cases of this, and we should have a simple, predictable approach to dealing with it. At a high-level, my view is that (within reason) blobs should be captured at the point of entry into the native API. As soon as you say img.srcset = '...; blob URL; ...', or xhr.open(objectURL), or img.src = createObjectURL(), that point where the URL first enters the native API is what matters. That's a simple rule that's easy for developers to understand in general, without needing to care about when or how many times the fetch algorithm is run (if ever, as with srcset) on the URLs. -- Glenn Maynard
Re: Rough summary of minutes from the face to face
On Tue, May 7, 2013 at 3:16 AM, Charles McCathie Nevile cha...@yandex-team.ru wrote: I'm interested in whether this was a useful exercise, by the way. It's missing the bit where you are going to attempt to fork my work on URLs ;-) -- http://annevankesteren.nl/
jar protocol (was: ZIP archive API?)
On 06/05/2013 20:42 , Jonas Sicking wrote: The only things that implementations can do that JS can't is: * Implement new protocols. I definitely agree that we should specify a jar: or archive: protocol, but that's orthogonal to whether we need an API. Have you looked at just reusing JAR for this (given that you support it in some form already)? I wonder how well it works. Off the top of my head I see at least two issues: • Its manifest format has lots of useless stuff, and is missing some things we would likely want (like MIME type mapping). • It requires its own URI scheme, which means that there is essentially no transition strategy for content: you can only start using it when everyone is (or you have to do UA detection). I wonder if we couldn't have a mechanism that would not require a separate URI scheme. Just throwing this against the wall, might be daft: We add a new link relationship: bundle (archive is taken, bikeshed later). The href points to the archive, and there can be as many as needed. The resolved absolute URL for this is added to a list of bundles (there is no requirement on when this gets fetched, UAs can do so immediately or on first use depending on what they wish to optimise for). After that, whenever there is a fetch for a resource the URL of which is a prefix match for this bundle the content is obtained from the bundle. This isn't very different from JAR but it does have the property of more easily enabling a transition. To give an example, say that the page at http://berjon.com/ contains: link rel=bundle href=bundle.wrap and img src=bundle.wrap/img/dahut.png alt=a dahut A UA supporting this would grab the bundle, then extract the image from it. A UA not supporting this would do nothing with the link, but would issue a request for /bundle.wrap/img/dahut.png. It is then fairly easy on the server side to be able to detect that it's a wrapped resource and serve it from inside the bundle (or whatever local convention it wants to adopt that allows it to cater to both — in any case it's trivial). This means no URL scheme to be supported by everyone, no nested URL scheme the way JAR does it (which is quite distasteful), no messing with escaping ! in paths, etc. WDYT? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Blob URLs | autoRevoke, defaults, and resolutions
On Mon, May 6, 2013 at 11:11 PM, Jonas Sicking jo...@sicking.cc wrote: The only thing that's different about XHR is that the first step in my list lives in one function, and the other steps live in another function. Doesn't seem to have any effect on the discussions here other than that we'd need to define which of the two functions does the step which grabs a reference to the Blob. Fair enough. So I guess we can indeed fix this by changing http://fetch.spec.whatwg.org/#concept-fetch to get a reference to the Blob/MediaStream/... before returning early as Arun suggested. -- http://annevankesteren.nl/
Change of affiliation
Dear All, From today, I am representing Mozilla in this WG. Kind regards, Marcos -- Marcos Caceres
Re: Re: [XHR] test nitpicks: MIME type / charset requirements
On Tue, May 7, 2013 at 2:39 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: TL;DR: I'm not aware of evidence that spec'ing this is required for compat, I do buy the argument that precision might cause better future compat, I'm however concerned about back compat and find it surprising that a strictly spec'ed implementation detail will sometimes transform the case the script actually used. Yeah, we might have to preserve casing of the encoding label if there's a (byte case-insensitive) match to begin with. -- http://annevankesteren.nl/
Re: jar protocol (was: ZIP archive API?)
On Tue, May 7, 2013 at 7:29 AM, Robin Berjon ro...@w3.org wrote: This isn't very different from JAR but it does have the property of more easily enabling a transition. To give an example, say that the page at http://berjon.com/ contains: link rel=bundle href=bundle.wrap and img src=bundle.wrap/img/dahut.png alt=a dahut You need a new URL scheme here. Otherwise the URL will be parsed relative to the node's base URL. -- http://annevankesteren.nl/
Re: jar protocol (was: ZIP archive API?)
* Anne van Kesteren wrote: On Tue, May 7, 2013 at 7:29 AM, Robin Berjon ro...@w3.org wrote: This isn't very different from JAR but it does have the property of more easily enabling a transition. To give an example, say that the page at http://berjon.com/ contains: link rel=bundle href=bundle.wrap and img src=bundle.wrap/img/dahut.png alt=a dahut You need a new URL scheme here. Otherwise the URL will be parsed relative to the node's base URL. Robin seems to address that in the parts of his mail you didn't quote. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: jar protocol (was: ZIP archive API?)
On Tue, May 7, 2013 at 11:34 AM, Bjoern Hoehrmann derhoe...@gmx.net wrote: Robin seems to address that in the parts of his mail you didn't quote. My bad :-( Have to say it does seem quite elegant. And has great fallback (if implemented on the server). -- http://annevankesteren.nl/
Re: jar protocol (was: ZIP archive API?)
On Tue, May 7, 2013 at 7:29 AM, Robin Berjon ro...@w3.org wrote: On 06/05/2013 20:42 , Jonas Sicking wrote: The only things that implementations can do that JS can't is: * Implement new protocols. I definitely agree that we should specify a jar: or archive: protocol, but that's orthogonal to whether we need an API. Have you looked at just reusing JAR for this (given that you support it in some form already)? I wonder how well it works. Off the top of my head I see at least two issues: • Its manifest format has lots of useless stuff, and is missing some things we would likely want (like MIME type mapping). • It requires its own URI scheme, which means that there is essentially no transition strategy for content: you can only start using it when everyone is (or you have to do UA detection). I wonder if we couldn't have a mechanism that would not require a separate URI scheme. Just throwing this against the wall, might be daft: We add a new link relationship: bundle (archive is taken, bikeshed later). The href points to the archive, and there can be as many as needed. The resolved absolute URL for this is added to a list of bundles (there is no requirement on when this gets fetched, UAs can do so immediately or on first use depending on what they wish to optimise for). After that, whenever there is a fetch for a resource the URL of which is a prefix match for this bundle the content is obtained from the bundle. This isn't very different from JAR but it does have the property of more easily enabling a transition. To give an example, say that the page at http://berjon.com/ contains: link rel=bundle href=bundle.wrap and img src=bundle.wrap/img/dahut.png alt=a dahut A UA supporting this would grab the bundle, then extract the image from it. A UA not supporting this would do nothing with the link, but would issue a request for /bundle.wrap/img/dahut.png. It is then fairly easy on the server side to be able to detect that it's a wrapped resource and serve it from inside the bundle (or whatever local convention it wants to adopt that allows it to cater to both — in any case it's trivial). This means no URL scheme to be supported by everyone, no nested URL scheme the way JAR does it (which is quite distasteful), no messing with escaping ! in paths, etc. WDYT? Will this let us support reading things from blob: URLs where the Blob contains a zip file? I.e. what Gecko would support as jar:blob:abc-123!/img/foo.jpg. Also note that while we're using jar as scheme name, it's simply just zip support. None of the other pieces of the jar spec is used. / Jonas
Re: Blob URLs | autoRevoke, defaults, and resolutions
On May 7, 2013, at 10:45 AM, Anne van Kesteren wrote: On Mon, May 6, 2013 at 11:11 PM, Jonas Sicking jo...@sicking.cc wrote: The only thing that's different about XHR is that the first step in my list lives in one function, and the other steps live in another function. Doesn't seem to have any effect on the discussions here other than that we'd need to define which of the two functions does the step which grabs a reference to the Blob. Fair enough. So I guess we can indeed fix this by changing http://fetch.spec.whatwg.org/#concept-fetch to get a reference to the Blob/MediaStream/... before returning early as Arun suggested. \o/ :-) Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=21955 -- A*
Re: Blob URLs | autoRevoke, defaults, and resolutions
On Tue, May 7, 2013 at 12:17 PM, Arun Ranganathan a...@mozilla.com wrote: \o/ :-) Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=21955 So actually, after I emailed that this morning I wondered how this would work for img srcset or image() in CSS where fetch is unlikely to be sync. Most of those are new features which might explain why it has not been seen as a problem thus far. -- http://annevankesteren.nl/
Re: jar protocol (was: ZIP archive API?)
* Robin Berjon wrote: I wonder if we couldn't have a mechanism that would not require a separate URI scheme. Just throwing this against the wall, might be daft: We add a new link relationship: bundle (archive is taken, bikeshed later). The href points to the archive, and there can be as many as needed. The resolved absolute URL for this is added to a list of bundles (there is no requirement on when this gets fetched, UAs can do so immediately or on first use depending on what they wish to optimise for). After that, whenever there is a fetch for a resource the URL of which is a prefix match for this bundle the content is obtained from the bundle. There have been many proposals over the years that would allow for some- thing like this, http://www.w3.org/TR/DataCache/ for instance, allows to intercept certain requests to aid in supporting offline applications, and `registerProtocolHandler` combined with `web+`-schemes go into a si- milar direction. Those seem more worthwhile to explore to me than your one-trick-strawman. Also, it is not clear to me that avoiding a special scheme is a useful design constraint (not to mention that bundling is something the com- puter is supposed to do for me, so I would want to get that out of my face). But I can see value in a more generic feature that allows me to implement and reference IO objects as I see fit, which would provide for bundling features. This means no URL scheme to be supported by everyone, [...] Well, `rel='bundle'` would have to be supported by everyone, because past critical mass there would be too many nobody noticed the fallback is not working until now cases, so that seems rather uninteresting in the longer term. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Blob URLs | autoRevoke, defaults, and resolutions
On Tue, May 7, 2013 at 9:45 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 6, 2013 at 11:11 PM, Jonas Sicking jo...@sicking.cc wrote: The only thing that's different about XHR is that the first step in my list lives in one function, and the other steps live in another function. Doesn't seem to have any effect on the discussions here other than that we'd need to define which of the two functions does the step which grabs a reference to the Blob. Fair enough. So I guess we can indeed fix this by changing http://fetch.spec.whatwg.org/#concept-fetch to get a reference to the Blob/MediaStream/... before returning early as Arun suggested. Step 1 is resolve, step 3 is fetch. Moving it into step 1 means it would go in resolve, not fetch. Putting it in fetch wouldn't help, since fetch doesn't always start synchronously. (I'm confused, because we've talked about this distinction several times.) -- Glenn Maynard
Re: Proposal for a DOM L3 Events Telecon
On Tue, May 7, 2013 at 1:39 AM, Masayuki Nakano masay...@d-toybox.comwrote: Hello, sorry for the big delay due to my business trip and holiday week of Japan. I'm available on either schedule. When I join the telecon, how can I join it? Skype or something? Excellent question - I'm wondering the same thing. Will this be using Zakim (http://www.w3.org/2002/01/UsingZakim) and will we have an IRC channel as well? -Gary
Re: Blob URLs | autoRevoke, defaults, and resolutions
I'd be worried about letting any resolved URL to hold a reference to the Blob. We are playing very fast and loose with URLs in Gecko and it's never been intended that they hold on to any resources of significant size. / Jonas On Tue, May 7, 2013 at 1:34 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, May 7, 2013 at 9:45 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 6, 2013 at 11:11 PM, Jonas Sicking jo...@sicking.cc wrote: The only thing that's different about XHR is that the first step in my list lives in one function, and the other steps live in another function. Doesn't seem to have any effect on the discussions here other than that we'd need to define which of the two functions does the step which grabs a reference to the Blob. Fair enough. So I guess we can indeed fix this by changing http://fetch.spec.whatwg.org/#concept-fetch to get a reference to the Blob/MediaStream/... before returning early as Arun suggested. Step 1 is resolve, step 3 is fetch. Moving it into step 1 means it would go in resolve, not fetch. Putting it in fetch wouldn't help, since fetch doesn't always start synchronously. (I'm confused, because we've talked about this distinction several times.) -- Glenn Maynard
Re: Blob URLs | autoRevoke, defaults, and resolutions
Fwiw, to the extent it may be helpful when it comes to spec writing, here are some quick-n-dirty thoughts about how some approximation of the 'autorevoke' behavior could be implemented in chromium. 1) Extend the lifetime of the PublicBlobURL registration until *after* the last latchee has redeemed its ticket to ride the url. The url registration itself is refcounted. The url registration implies the underlying data is not reclaimable. At time of coining the url registration, a microtask is scheduled to release it. Latchee's may addref it safely prior to microtask execution, keeping the url registration valid until a later balancing release. This would be a non-compliant approximation of the way the spec is shaping up... but good enough... maybe has the important characteristics of freeing memory up eventually (generally prior to doc unload) and guaranteeing a latchee's ticket to ride. 2) Extend the lifetime of the underlying BlobData until *after* the latchee has redeemed its ticket to ride the url, but revoke the URL well in advance of that. The url registration is not refcounted, The url registration implies the underlying data is not reclaimable. There is a means to lookup a handle to the data given the url. The underlying blob data is refcounted. Latchee's must take and release a ref on that. The url registration is revoked at microtask execution time after being coined. Piggy back a handle to the blob data on future Fetch (or other network requests) for the PublicBlobURL. Ignore the URL when processing those requests and refer only to the piggybacked blob data handle. Probably a more compliant approach, but maybe more tedious to implement in chromium (since the URL is no longer useful as the identifier for what to fetch/load/whathaveyou, we need sideband data for that in addition to addref/release at url latch/redemption times). (I'm confused, because we've talked about this distinction several times.) lol, picture a herd of cats chasing their tails, you can call me calico :) On Tue, May 7, 2013 at 1:34 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, May 7, 2013 at 9:45 AM, Anne van Kesteren ann...@annevk.nlwrote: On Mon, May 6, 2013 at 11:11 PM, Jonas Sicking jo...@sicking.cc wrote: The only thing that's different about XHR is that the first step in my list lives in one function, and the other steps live in another function. Doesn't seem to have any effect on the discussions here other than that we'd need to define which of the two functions does the step which grabs a reference to the Blob. Fair enough. So I guess we can indeed fix this by changing http://fetch.spec.whatwg.org/#concept-fetch to get a reference to the Blob/MediaStream/... before returning early as Arun suggested. Step 1 is resolve, step 3 is fetch. Moving it into step 1 means it would go in resolve, not fetch. Putting it in fetch wouldn't help, since fetch doesn't always start synchronously. (I'm confused, because we've talked about this distinction several times.) -- Glenn Maynard
Re: Blob URLs | autoRevoke, defaults, and resolutions
On Tue, May 7, 2013 at 2:54 PM, Jonas Sicking jo...@sicking.cc wrote: I'd be worried about letting any resolved URL to hold a reference to the Blob. We are playing very fast and loose with URLs in Gecko and it's never been intended that they hold on to any resources of significant size. That said, the one way to find out if this approach works is to simply try it. / Jonas
Re: ZIP archive API?
* Florian Bösch wrote: It can be implemented by a JS library, but the three reasons to let the browser provide it are Convenience, speed and integration. Convenience is the first reason, since browsers by far and large already have complete bindings to compression algorithms and archive formats, letting the browser simply expose the software it already ships makes good sense rather than requiring every JS user to supply his own version. Speed may not matter to much on some platforms, but it matters a great deal on underpowered devices such as mobiles. Integration is where the support for archives goes beyond being an API, where URLs (to link.href, script.src, img.src, iframe.src, audio.src, video.src, css url(), etc.) could point into an archive. This cannot be done in JS. If we all agreed that such functionality should be provided by libraries rather than browser cores, and browser vendors could be expected to make things convenient, fast, and well-integrated, then using libraries would be convenient, libraries would be fast, and they would integrate well. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Proposal for a DOM L3 Events Telecon
On Tue, 07 May 2013 23:07:28 +0200, Gary Kačmarčík (Кошмарчик) gary...@google.com wrote: On Tue, May 7, 2013 at 1:39 AM, Masayuki Nakano masay...@d-toybox.comwrote: Hello, sorry for the big delay due to my business trip and holiday week of Japan. I'm available on either schedule. When I join the telecon, how can I join it? Skype or something? Excellent question - I'm wondering the same thing. Will this be using Zakim (http://www.w3.org/2002/01/UsingZakim) and will we have an IRC channel as well? We can certainly ask for a zakim slot. I strongly suggest using IRC as well, especially to help Masayuki follow (which means someone needs to scribe...) cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
RE: Proposal for a DOM L3 Events Telecon
Yeah, we'll be on #webapps, and I can invite Zakim. I can also provide call-in instructions for the Microsoft bridge from irc. -Original Message- From: Charles McCathie Nevile [mailto:cha...@yandex-team.ru] Sent: Tuesday, May 7, 2013 3:01 PM To: Masayuki Nakano; Gary Kačmarčík (Кошмарчик) Cc: Travis Leithead; public-webapps; www-dom Subject: Re: Proposal for a DOM L3 Events Telecon On Tue, 07 May 2013 23:07:28 +0200, Gary Kačmarčík (Кошмарчик) gary...@google.com wrote: On Tue, May 7, 2013 at 1:39 AM, Masayuki Nakano masay...@d-toybox.comwrote: Hello, sorry for the big delay due to my business trip and holiday week of Japan. I'm available on either schedule. When I join the telecon, how can I join it? Skype or something? Excellent question - I'm wondering the same thing. Will this be using Zakim (http://www.w3.org/2002/01/UsingZakim) and will we have an IRC channel as well? We can certainly ask for a zakim slot. I strongly suggest using IRC as well, especially to help Masayuki follow (which means someone needs to scribe...) cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Proposal for a DOM L3 Events Telecon
The PIN for this call (starts at the top of the hour which is 19:00 Boston time) is 26632. On 5/7/13 6:03 PM, ext Travis Leithead wrote: Yeah, we'll be on #webapps, and I can invite Zakim. I can also provide call-in instructions for the Microsoft bridge from irc. -Original Message- From: Charles McCathie Nevile [mailto:cha...@yandex-team.ru] Sent: Tuesday, May 7, 2013 3:01 PM To: Masayuki Nakano; Gary Kačmarčík (Кошмарчик) Cc: Travis Leithead; public-webapps; www-dom Subject: Re: Proposal for a DOM L3 Events Telecon On Tue, 07 May 2013 23:07:28 +0200, Gary Kačmarčík (Кошмарчик) gary...@google.com wrote: On Tue, May 7, 2013 at 1:39 AM, Masayuki Nakano masay...@d-toybox.comwrote: Hello, sorry for the big delay due to my business trip and holiday week of Japan. I'm available on either schedule. When I join the telecon, how can I join it? Skype or something? Excellent question - I'm wondering the same thing. Will this be using Zakim (http://www.w3.org/2002/01/UsingZakim) and will we have an IRC channel as well? We can certainly ask for a zakim slot. I strongly suggest using IRC as well, especially to help Masayuki follow (which means someone needs to scribe...) cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: Blob URLs | autoRevoke, defaults, and resolutions
On Tue, May 7, 2013 at 4:54 PM, Jonas Sicking jo...@sicking.cc wrote: I'd be worried about letting any resolved URL to hold a reference to the Blob. We are playing very fast and loose with URLs in Gecko and it's never been intended that they hold on to any resources of significant size. Note that I'm not suggesting that every invocation of the resolve algorithm start capturing blob URLs. It'd be an explicit operation at entry points that support it, not a catch-all happening behind the scenes any time you resolve a URL anywhere. (Actually, I went a bit further--entry points that don't explicitly do this shouldn't allow autorevoke URLs at all.) The actual change required in the particular entry points might be as simple as saying resolve URL with capture instead of resolve URL to invoke a wrapper algorithm, but it lets it be introduced gradually and make it clear exactly where it happens. -- Glenn Maynard
Re: jar protocol (was: ZIP archive API?)
On Tue, May 7, 2013 at 9:29 AM, Robin Berjon ro...@w3.org wrote: Have you looked at just reusing JAR for this (given that you support it in some form already)? I wonder how well it works. Off the top of my head I see at least two issues: JARs are just ZIPs with Java metadata. We don't need metadata, so plain ZIPs are enough. link rel=bundle href=bundle.wrap and img src=bundle.wrap/img/dahut.**png alt=a dahut This depends on a document, so it wouldn't work in workers unless we add a second API to register them in script. -- Glenn Maynard
WebApps DOM3 Events Wiki page
Hey folks, I just posted the raw minutes to the DOM 3 Events wiki page: http://www.w3.org/2008/webapps/wiki/DOM3Events http://www.w3.org/2008/webapps/wiki/Bi-weekly_meetings The page itself is a derelict from ages past, and I haven’t made much of an effort to clean it up, but it does have a new section for Meetings, and a place to propose an agenda. The minutes span the mightnight rollover on some server, so they are not contiguous, and I failed to find a way to automatically stich them together, so they are in two parts. Art, I’d love any pointers to how to clean them up… ☺ Thanks everyone for the call. See you in two weeks.
