Re: Art steps down - thank you for everything
Thank you Art! It has been a great experience and joy working with you. Your calm leadership and warm support will be missed. On Sat, Jan 30, 2016 at 4:18 AM, Alex Russell <slightly...@google.com> wrote: > Sorry to hear you're leaving us, Art. Your skills and humor will be missed. > > On Fri, Jan 29, 2016 at 7:51 AM, Philippe Le Hegaret <p...@w3.org> wrote: > >> Thank you Art. >> >> You carried out this group and community over so many years. >> >> Your first email to the AC was entitled "Just say NO?" as a response to a >> proposal from W3C. It will take a while for me to realize you won't be >> standing and come to the microphone to challenge us as you used to do for >> so many years. >> >> Philippe >> >> >> On 01/28/2016 10:45 AM, Chaals McCathie Nevile wrote: >> >>> Hi folks, >>> >>> as you may have noticed, Art has resigned as a co-chair of the Web >>> Platform group. He began chairing the Web Application Formats group >>> about a decade ago, became the leading co-chair when it merged with Web >>> APIs to become the Web Apps working group, and was instrumental in >>> making the transition from Web Apps to the Web Platform Group. (He also >>> chaired various other W3C groups in that time). >>> >>> I've been very privileged to work with Art on the webapps group for so >>> many years - as many of you know, without him it would have been a much >>> poorer group, and run much less smoothly. He did a great deal of work >>> for the group throughout his time as co-chair, efficiently, reliably, >>> and quietly. >>> >>> Now we are three co-chairs, we will work between us to fill Art's shoes. >>> It won't be easy. >>> >>> Thanks Art for everything you've done for the group for so long. >>> >>> Good luck, and I hope to see you around. >>> >>> Chaals >>> >>> >> > -- Jungkee Song
Service Workers 1 and Nightly
Hi all, We editors are happy to announce that we make a new branch for Service Workers 1 today [1]. Thanks to all the contributions, Service Workers 1 now covers the fundamental model and the associated APIs to support offline-first and background processing requirements. The features in this version include: - Register/Update/Unregister of a service worker registration - Handle fetch events - Fetch and Cache resources - Manage service worker clients - Communicate between a client and a service worker - Define interfaces and algorithms for extensions (Push, Notification, etc.) ([2] is the remaining issues for this version in the github issue tracker.) On top of the above work, the contributors are now ready to continue with the discussions about new features including foreign fetch [3], fetch event's request's client, header-based installation, kill-switch, and so forth. These efforts will be put in Service Workers Nightly [4] which is just a new name for the original ED branch. We are planning to publish a CR based on Service Workers 1 soon during which we would like to focus on stabilizing the features (bug fix) and resolving compatibility issues among multiple implementations. For editors, Jungkee [1] https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/ [2] https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3Aissue+m ilestone%3A%22Version+1%22 [3] https://github.com/slightlyoff/ServiceWorker/issues/684 [4] https://slightlyoff.github.io/ServiceWorker/spec/service_worker/ -- Jungkee Song Samsung Electronics
Re: Service Workers 1 and Nightly
On Fri, Sep 18, 2015 at 7:56 PM, Arthur Barstow <art.bars...@gmail.com> wrote: > > Regarding the publishing plan above, the latest process document includes > an expectation that before a CR is published the spec "has already received > wide review" [1]. Although the group is free to determine the wide review > "requirements" (see [2]), it can be useful to publish a new WD and use that > WD as the basis of the wide review. It would also be possible to use an ED > (perhaps a static snapshot) as the basis for the review. There is also a > question about which group(s) we explicitly want to ask to review the spec. > > What are your thoughts on the document (WD vs. ED snapshot) to use as the > review? > If there's no particular problem, an ED snapshot would be great to avoid redundant publication preparations. In that case, I'll try to get it well prepared before we request it. > > Which groups do we ask to review? I presume at least TAG and Web Mobile > IG. Are there others? > I presume TAG, Web Mobile IG, WebAppSec (Security standpoint), Geolocation WG (Geofencing uses SW) would be good. Any other suggestions? Thanks, Jungkee > > -Thanks, AB > > [1] <http://www.w3.org/2015/Process-20150901/#maturity-levels> > [2] <http://www.w3.org/2015/Process-20150901/#wide-review> > > -- Jungkee Song
RE: W3C's version of XMLHttpRequest should be abandoned
Hi Art, Hallvord, Julian, and all, Apologies having not been active on it. My feeling is capturing a snapshot for REC would still be a non-trivial task. Unfortunately, I don't seem to be able to spare much time on this work as of now. Sorry for not being able to help. It's my own stance, not the other editors. Domenic's suggestion sound reasonable to me if we are not coming up with a better plan. Best regards, Jungkee -Original Message- From: Arthur Barstow [mailto:art.bars...@gmail.com] Sent: Friday, August 07, 2015 8:37 PM To: Hallvord Reiar Michaelsen Steen; Jungkee Song; Julian Aubourg Cc: WebApps WG Subject: Re: W3C's version of XMLHttpRequest should be abandoned On 8/6/15 8:07 AM, Hallvord Reiar Michaelsen Steen wrote: On Thu, Aug 6, 2015 at 9:15 AM, Anne van Kesteren ann...@annevk.nl mailto:ann...@annevk.nl wrote: According to Art the plan of record is to still pursue https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html And you correctly note but that was last updated more than a year ago. Last formally published a year and a half ago. And that is mostly my fault. I intended to keep the W3C fork up to date (at least up to a point), but at some point I attempted to simply apply Git patches from Anne's edits to the WHATWG version, and it turned out Git had problems applying them automatically for whatever reason - apparently the versions were already so distinct that it wasn't possible. Since then I haven't found time for doing the manual cut-and-paste work required, and I therefore think it's probably better to follow Anne's advice and drop the W3C version entirely in favour of the WHATWG version. I still like the idea of having a stable spec documenting the interoperable behaviour of XHR by a given point in time - but I haven't been able to prioritise it and neither, apparently, have the other two editors. Jungkee, Julian - we would like your input, in particular whether or not you can still commit to helping with the tasks required to move XHR Level 1 along the Recommendation track. Others - if you can commit to helping with the main tasks (editing, testing, implementation, etc.) for XHR L1, please let us know. -Thanks, AB
RE: PSA: publishing new WD of Service Workers on June 25
Thanks for comments. I'll address them in the ED. I didn't get through them all yet, but * in parallel isn't defined, but it sounds like you mean in parallel to the main sequence not in parallel to themselves, I'd strongly encourage a definition. in parallel is defined here: https://html.spec.whatwg.org/multipage/infrastructure.html#in-parallel. Will add the links. Jungkee -Original Message- From: timeless [mailto:timel...@gmail.com] Sent: Wednesday, July 01, 2015 1:23 PM To: public-webapps Subject: Re: PSA: publishing new WD of Service Workers on June 25 http://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD- service-workers-20150625/ Invoke Run Service Worker algorithm with serviceWorker as the arguement [sic]. Fetch invokes Handle Fetch with request. As a result of performing Handle Fetch, the Service Woker [sic] returns a response to Fetch. If the client request is under the scope of a service worker registration, appplication [sic] cache is completely bypassed regardless of whether the client request uses the service worker registration. Events that correspond to network requests are dispatched to the worker and the responses generated by the worker may over-ride* default network stack behavior. override en-us: Let the origin attribute of e be initialized to the Unicode serialisation* of the origin specified by the incumbent settings object. Service workers define the following behaviours* for install event and activate event: When a service worker client is controlled by an active worker, it is considered the service worker client is using the active worker's containing service worker registration. this is awkward, you might add `that` after `it is` This is conceptually the same operation that UA does maximum once per every 24 hours. this is awkward, you might add `the` before `UA`, `a` after `does` and `of` before `once`. Run the following substeps in parallel: 1. CheckRegistration: If the result of running Match Service Worker Registration algorithm, or its equivalent, with clientURL as its argument is not null, then: 1.1. Set registration to the result value. 2. Else: Else seems odd for `run...in parallel` 2.1. Wait until scope to registration map has a new entry. 2.2. Jump to the step labeled CheckRegistration. cat spec|grep 'in parallel' | perl -pne 's/\s*,.*,\s*/ ... /;s/.*( run)/$1/;s/(the ).*( handler)/$1...$2/;s/^\s*/ /'|sort|uniq - c|sort -n|perl -pne 's/(?:\s*)(\d*)\s*(.*)\n/$2 [$1]\n/' Return the ... handler ... performs the following substeps in parallel: [1] Return the ... handler that performs the following substeps in parallel: [1] Run the following in parallel: [1] Set p to the ... handler that ... performs the following substeps in parallel: [1] run the following substeps in parallel: [1] Return the ... handler that ... performs the following substeps in parallel: [4] run the following substeps in parallel. [4] Run these steps in parallel: [7] Run the following substeps in parallel: [10] * you use steps|substeps interchangeably afaict; you sometimes don't use *steps... * you use .|: interchangeably * various other inconsistent stylistic elements can be seen from the above list... * in parallel isn't defined, but it sounds like you mean in parallel to the main sequence not in parallel to themselves, I'd strongly encourage a definition. The following are the event handlers (and its corresponding event handler event types) that must be supported, pattern: event handlers [plural!] (and its ...) its = their The service worker registration's installing worker changes. (See step 8 of the Install algorithm). A WindowClient object has an associated focus state, which is either true or false. (Initially false). pattern: misplaced `.` When event.respondWith(r) method is invoked, the argument, r, must resolve with a Response, else a network error is returned to Fetch. `must .. else` is an odd construct. normally `or` is appropriate... The Cache objects do not expire unless authors delete the entries. `objects ... the entries` is odd the entries = them | objects = object entries ?? This implies that authors should version their caches by name and make sure to **use the caches only from the version of the service worker that can safely operate on**. ... = to only use caches that can be safely operated by the current version of the service worker. Cache objects are always enumerable via self.caches in insertion order (per ECMAScript 6 Map objects.) Resolve p with the result of running the algorithm specified in match(request, options) method of Cache interface with request and options as the arguments (providing entry.[[value]] as thisArgument to the [[Call]] internal method of match(request, options).) pattern: misplaced `.` (the other way...) If r's method is
Re: [push-api] Moving PushManager push onto ServiceWorkerRegistration
On Jul 12, 2014 2:11 AM, Jake Archibald jaffathec...@gmail.com wrote:
On 11 July 2014 17:59, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jul 11, 2014 at 8:17 AM, Jake Archibald jaffathec...@gmail.com
wrote:
navigator.serviceWorker.ready.then(function(reg) {
reg.push.register(...)
});
I agree this looks good. Though maybe
reg.registerPush(...)
instead?
.push also has .unregister, will probably have .hasPermission too.
Other Service Worker dependent specs may want to do the same, so each API
having its own namespace seems good. e.g:
// IDL
partial interface ServiceWorkerRegistration {
readonly attribute TaskScheduler taskScheduler;
}
partial interface ServiceWorkerGlobalScope {
attribute EventHandler onalarm;
};
// JS
navigator.serviceWorker.ready.then(function(reg) {
reg.taskScheduler.add(Date.now() + (10 * 6), ...);
});
(the current spec has .registrations, but I believe one registration per
serivceworker is the rule now)
Re: Service worker spec should probably not use IDL arrays
On May 9, 2014 12:19 PM, Boris Zbarsky bzbar...@mit.edu wrote: IDL arrays are not really supported by any UA, and it's not clear to me that any plan to do it. The trend has been toward using ES arrays instead (which typically means IDL sequences). At first glance, every use of IDL arrays in service workers could in fact be a sequence without causing any obvious problems Addressed: https://github.com/slightlyoff/ServiceWorker/commit/0035befac6c49df5b2e7a171ce26aa96c516a32d Thanks for the comment. -Boris
Re: Why do keys() and values() on CacheList in ServiceWorkers not return promises
On May 9, 2014 1:16 PM, Boris Zbarsky bzbar...@mit.edu wrote: In particular, given that get() wants to return a Promise, why do we want values() to return a list of Cache objects synchronously? Similar for keys(): if has() needs to be async, then how can has() be sync. Exactly. both values() and keys() will be changed to async returning Promises. I'll be working on that part of the ED shortly. It's a bit behind the discussion going on in this ticket: https://github.com/slightlyoff/ServiceWorker/issues/226 -Boris
Re: XMLHttpRequest Level 1- specification history
On Sun, Mar 30, 2014 at 8:56 AM, Ian Hickson i...@hixie.ch wrote: On Sat, 29 Mar 2014, David Dailey wrote: The XMLHttpRequest http://www.w3.org/TR/XMLHttpRequest/#xmlhttprequest object was initially defined as part of the WHATWG's HTML effort. (Long after Microsoft shipped an implementation.) To me this is ambiguous: It could either mean 1. Long after Microsoft had shipped a related implementation, the XMLHttpRequest http://www.w3.org/TR/XMLHttpRequest/#xmlhttprequest object was defined as part of the WHATWG's HTML effort This is correct. I presume the author originally put the part rather informatively. I made it a single sentence as clarified here: https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html#specification-history Thanks, 2.The XMLHttpRequest http://www.w3.org/TR/XMLHttpRequest/#xmlhttprequest object was initially defined as part of the WHATWG's HTML effort. (Much later, Microsoft shipped an implementation.) If this was the meaning, you would need a comma after Long after. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Jungkee Song
Re: XMLHttpRequest Level 1- specification history
On Mon, Mar 31, 2014 at 2:44 AM, Ian Hickson i...@hixie.ch wrote: On Sun, 30 Mar 2014, Jungkee Song wrote: I presume the author originally put the part rather informatively. I made it a single sentence as clarified here: https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html#specification-history Oh, man, please don't fork this further! The canonical spec for XHR is Anne's, at http://xhr.spec.whatwg.org/. I really would rather the W3C stopped causing all this confusion with all these forks of WHATWG specs. It's harming the Web. This snapshot is not to develop the features in its own way but to provide the work for the implementors to test and achieve the compatibility with. I think the related testing efforts [1] (the current status [2]) from many industry players (of course Anne contributed enormous part of the test too) are improving the Web in a way. [1] http://w3c-test.org/XMLHttpRequest/ [2] http://jungkees.github.io/XMLHttpRequest-test/ -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Jungkee Song
Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)
On Feb 17, 2014 8:02 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 16, 2014, at 2:16 AM, Marcos Caceres mar...@marcosc.com wrote: On Sunday, February 16, 2014, Alex Russell slightly...@google.com wrote: On Sat, Feb 15, 2014 at 5:56 AM, Marcos Caceres w...@marcosc.com wrote: tl;dr: I strongly agree (and data below shows) that installable web apps without offline capabilities are essentially useless. Things currently specified in the manifest are supposed to help make these apps less useless (as I said in the original email, they by no means give us the dream of installable web apps, just one little step closer) - even if we had SW tomorrow, we would still need orientation, display mode, start URL, etc. So yes, SW and manifest will converge... questions for us to decide on is when? And if appcache can see us through this transitional period to having SW support in browsers? I believe we can initially standardize a limited set of functionality, while we continue to wait for SW to come into fruition which could take another year or two. SW will becoming to chrome ASAP. We're actively implementing. Jonas or Nikhil can probably provide more Mozilla context. I'm also interested in the WebKit and Microsoft context. I just don't know who to ask there. Have their been any public signals of their level of interest in SW? In general I think it's a good idea and I bet many other WebKit folks do too. We haven't yet had a chance to review thoroughly but I expect we'll like the general principles. I personally would like to see it become an official draft of the Working Group if it isn't already (the Publication Status page implies not, but perhaps I have missed something). If it is being actively implemented, it would be great to publish it as a Working Draft also, so we can get the IPR disclosures out of the way. Regards, Maciej Great to hear that. The standard track document is being drafted here. [1] It'll be nicer if WebKit folks have a chance to review the ongoing work [2] and join the iteration at this time. [1] http://rawgithub.com/slightlyoff/ServiceWorker/master/spec/service_worker/index.html [2] https://github.com/slightlyoff/ServiceWorker
Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)
On Mon, Feb 17, 2014 at 10:26 PM, Arthur Barstow art.bars...@nokia.comwrote: On 2/17/14 8:03 AM, ext Marcos Caceres wrote: On Monday, February 17, 2014 at 12:38 PM, Arthur Barstow wrote: BTW, I noticed there is no Bugzilla component for Service Workers so I will ask Mike Smith to create one). I think they bug tracker on GH is being used instead. It's already very active and it would be a shame to have to move to Bugzilla. I don't have a strong preference (Bugzilla vs. GH Issues) but I do think only one should be used and supported. Note the ED includes the following: [[ Participate File bugs https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=; blocked=14968short_desc=%5BCustom%5D%3A%20product= WebAppsWGcomponent=Service%20Workers(w3.org'sBugzilla https://www.w3.org/Bugs/Public/) ]] So I naturally assumed Bugzilla would be used (and if this isn't the case the above should be fixed/clarified). The work has been done in the GH repo and all the actual players are actively collaborating there using the GH issues. I think we should keep using it unless otherwise determined by the contributors. I'll fix the above text to point to the GH issues. -Thanks, AB -- Jungkee Song
Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)
On Mon, Feb 17, 2014 at 9:38 PM, Arthur Barstow art.bars...@nokia.comwrote: On 2/17/14 6:47 AM, ext Jungkee Song wrote: On Feb 17, 2014 8:02 PM, Maciej Stachowiak m...@apple.com mailto: m...@apple.com wrote: I personally would like to see it become an official draft of the Working Group if it isn't already Yes, me too. (the Publication Status page implies not, but perhaps I have missed something). (The data for the AppCache/ServiceWorkers row wasn't accurate, pending an update from the Editors. I just replaced that row with a single entry for Service Workers and included a link to the ED that Jungkee provided below.) Thanks for the update. If it is being actively implemented, it would be great to publish it as a Working Draft also, so we can get the IPR disclosures out of the way. Regards, Maciej Great to hear that. The standard track document is being drafted here. [1] It'll be nicer if WebKit folks have a chance to review the ongoing work [2] and join the iteration at this time. Jungkee, Alex - what needs to be done before Service Workers is ready for FPWD? The only process requirement for a FPWD is that the group record consensus to publish it. However, it's usually helpful if the FPWD is feature complete from a breadth perspective but there is no expectation the FPWD is complete from a depth perspective. As such, if there are missing features, it would be good to mention that in the ED and/or file related bugs. I believe things are mostly addressed in a breadth perspective albeit quite a few issues are still being discussed and sorted out. We are currently drafting the ED and thought the F2F is sort of a right time to have a consensus for FPWD but think it'll be nicer if we can make it even before that to get a wider review as soon as possible. BTW, I noticed there is no Bugzilla component for Service Workers so I will ask Mike Smith to create one). -Thanks, AB [1] http://rawgithub.com/slightlyoff/ServiceWorker/ master/spec/service_worker/index.html [2] https://github.com/slightlyoff/ServiceWorker -- Jungkee Song
Re: [progress-events] Progress Events is a W3C Recommendation
Thanks Art. The work is attributed to Anne, Chaals and Ms2ger. Thanks! On Feb 12, 2014 9:28 PM, Arthur Barstow art.bars...@nokia.com wrote: Congratulations to Anne, Jungkee and Chaals on the publication of a Progress Events Recommendation http://www.w3.org/TR/2014/ REC-progress-events-20140211/ . (I updated this spec's PubStatus data to state that no additional work is planned and that the feature is now part of XHR.)
Re: [XHR] XHR 1 / XHR 2
On Feb 3, 2014 11:41 PM, Dominique Hazael-Massieux d...@w3.org wrote: Hi, The TR draft says that the URL of the editors draft is: https://dvcs.w3.org/hg/xhr/xhr-1/raw-file/tip/Overview.html I believe it is meant to be: https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html That's right. It's a mistake. Is there a way to running-change it? It sounds like the group decided to re-use the title XHR Level 1, while it covers the features that used to be in XHR Level 2. That's somewhat confusing (but it may be that it's the least confusing option?). Yes, there's been a decision as such. The history is that the short name XMLHttpRequest was started to be re-used from http://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/ which superseded the what had been referenced as XMLHttpRequest 1 back then as well. In any case, the XMLHttpRequest2 shortname still points to the old XHR Level 2 draft: http://www.w3.org/TR/XMLHttpRequest2/ That should be fixed one way or the other. Thanks for noticing. I'll take care of it discussing with co-editors. Thanks, Dom
Re: W3C XHR, was Re: [admin] Draft of updated charter available for review
On Fri, Jan 24, 2014 at 8:22 PM, Arthur Barstow art.bars...@nokia.comwrote: On 1/23/14 8:48 PM, ext Jungkee Song wrote: I understand your concern. Indeed, we editors should have made it clearer providing updates on the status and more importantly a new TR. The goal of the snapshot version of the spec is clear. It aims to standardize all widely implemented parts of the spec that are compatibly supported across major implementations in a *timely* manner. Hence the number one to-do is to enhance the pass ratio of the test suite [1] by interacting with the implementors. We'd planned to publish LC with the Level 1 spec [2] in a near-term after the last TPAC but the changing publication policy recommends for us to take more conservative approach in publishing LC. That said, it seems necessary for us to publish a WD with [2] for now before we'll get ready with the test results good enough for publishing LC. Any comments would be appreciated. Thanks for the update Jungkee! I think your plan (to publish a WD now that will replace the 2012 WD and to continue to work toward a LC that is broadly and compatibly implemented) is good. Please let me know when you want me to start a CfC for the WD. We editors agreed with requesting a CfC to publish [2] as a WD. I'll request it as soon as I'm ready with a WD-ready version. Thanks, Jungkee -Thanks, Art [1] http://jungkees.github.io/XMLHttpRequest-test/ [2] https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html -- Jungkee Song
[xhr-1] XMLHttpRequest Level 1 WD update
Thanks for all the comments. I've updated the WD of XMLHttpRequest Level 1 as such: https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/TR/Overview.html This version (Level 1) reflects all the up-to-date features in WHATWG version except: - The URLSearchParams type in send() method. - The additional methods other than append() defined in the interface FormData. (** Note: This version is not planned to be revised in the language of the WHATWG Fetch spec.) If you have any concerns about this draft, please leave your comments. Here's the reference urls to the relevant testing activities: Test suite: http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/ Test result: http://jungkees.github.io/XMLHttpRequest-test/ For the co-editors, On Jan 28, 2014 2:31 AM, Domenic Denicola dome...@domenicdenicola.com wrote: This sounds great. It would be cool if editors ping the relevant list as working drafts get updated, just so everyone can use the lists as an ambient feed of what's going on. But an actual CFC process seems unnecessary. -- *From:* Jonas Sicking jo...@sicking.cc *Sent:* Monday, January 27, 2014 12:18 *To:* Marcos Caceres *Cc:* public-webapps; Arthur Barstow *Subject:* Re: CFCs for ordinary drafts, was CFC for Re: W3C XHR, was Re: [admin] Draft of updated charter available for review For specs that are passed FPWD, and thus where consensus to publish there has been reached, this sounds like a good idea. Though it might also be good to enable anyone to raise concerns about a spec such that automatic WDs aren't published until concensus is reached again. / Jonas On Jan 27, 2014 7:49 AM, Marcos Caceres w...@marcosc.com wrote: Hi Art, I'm wondering if we can change the group's work mode to not requiring CFCs for ordinary working drafts? Unless I'm not getting something, they seem to add an unnecessary delay to getting stuff published. Kind regards, Marcos -- Marcos Caceres On Monday, January 27, 2014 at 3:37 PM, Jungkee Song wrote: On Fri, Jan 24, 2014 at 8:22 PM, Arthur Barstow art.bars...@nokia.com(mailto: art.bars...@nokia.com) wrote: On 1/23/14 8:48 PM, ext Jungkee Song wrote: I understand your concern. Indeed, we editors should have made it clearer providing updates on the status and more importantly a new TR. The goal of the snapshot version of the spec is clear. It aims to standardize all widely implemented parts of the spec that are compatibly supported across major implementations in a *timely* manner. Hence the number one to-do is to enhance the pass ratio of the test suite [1] by interacting with the implementors. We'd planned to publish LC with the Level 1 spec [2] in a near-term after the last TPAC but the changing publication policy recommends for us to take more conservative approach in publishing LC. That said, it seems necessary for us to publish a WD with [2] for now before we'll get ready with the test results good enough for publishing LC. Any comments would be appreciated. Thanks for the update Jungkee! I think your plan (to publish a WD now that will replace the 2012 WD and to continue to work toward a LC that is broadly and compatibly implemented) is good. Please let me know when you want me to start a CfC for the WD. We editors agreed with requesting a CfC to publish [2] as a WD. I'll request it as soon as I'm ready with a WD-ready version. Thanks, Jungkee -Thanks, Art [1] http://jungkees.github.io/XMLHttpRequest-test/ [2] https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html -- Jungkee Song
Re: W3C XHR, was Re: [admin] Draft of updated charter available for review
On Jan 24, 2014 7:48 AM, Marcos Caceres w...@marcosc.com wrote: On Thursday, January 23, 2014 at 10:36 PM, Marcos Caceres wrote: On Thursday, January 23, 2014 at 9:29 PM, Arthur Barstow wrote: I don't recall any discussions about stopping the current work, although I think it would be useful if the group's XHR Editors would provide a short status and plan. It would indeed be good. However, it would also be good to have a broader discussion about what we do about the specs that have move to the WHATWG (unless we already did that and I missed it). This whole snapshot thing doesn’t feel like it’s working IMO. To be clear: I’m concerned that the last time the spec on TR was updated was in 2012. That seems like a big failure to me, specially as when you google for the spec, the on the TR comes up first. This means that most people are looking at a grossly outdated spec if they click on the first link. I understand your concern. Indeed, we editors should have made it clearer providing updates on the status and more importantly a new TR. The goal of the snapshot version of the spec is clear. It aims to standardize all widely implemented parts of the spec that are compatibly supported across major implementations in a *timely* manner. Hence the number one to-do is to enhance the pass ratio of the test suite [1] by interacting with the implementors. We'd planned to publish LC with the Level 1 spec [2] in a near-term after the last TPAC but the changing publication policy recommends for us to take more conservative approach in publishing LC. That said, it seems necessary for us to publish a WD with [2] for now before we'll get ready with the test results good enough for publishing LC. Any comments would be appreciated. [1] http://jungkees.github.io/XMLHttpRequest-test/ [2] https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html
RE: CfC: publish Proposed Recommendation of Progress Events; deadline November 25
Hi, I've prepared the PR-ready version of the Progress Events spec: https://dvcs.w3.org/hg/progress/raw-file/tip/TR/Overview.html Please use this version to review and give further comments during the CfC period, if any. Jungkee -Original Message- From: Jungkee Song [mailto:jungkee.s...@samsung.com] Sent: Tuesday, November 19, 2013 4:43 PM To: 'Takeshi Yoshino' Cc: 'public-webapps' Subject: RE: CfC: publish Proposed Recommendation of Progress Events; deadline November 25 From: Takeshi Yoshino [mailto:tyosh...@google.com] Sent: Tuesday, November 19, 2013 1:48 PM two minor comments - add semicolons to lines of the example code in the introduction section? This might not be an issue but I agree to add them. - 2nd paragraph in the conformance section, quote must? It looks better. I'll put together a PR-ready draft incorporating the above comments. Also, please note that there was a minor change [1] in the ED [2], a year ago, which I'll use as a base document for the PR-ready draft. Thanks! [1] https://dvcs.w3.org/hg/progress/rev/964030fa5727 [2] https://dvcs.w3.org/hg/progress/raw-file/tip/Overview.html -- Jungkee Song Samsung Electronics
RE: CfC: publish Proposed Recommendation of Progress Events; deadline November 25
From: Takeshi Yoshino [mailto:tyosh...@google.com] Sent: Tuesday, November 19, 2013 1:48 PM two minor comments - add semicolons to lines of the example code in the introduction section? This might not be an issue but I agree to add them. - 2nd paragraph in the conformance section, quote must? It looks better. I'll put together a PR-ready draft incorporating the above comments. Also, please note that there was a minor change [1] in the ED [2], a year ago, which I'll use as a base document for the PR-ready draft. Thanks! [1] https://dvcs.w3.org/hg/progress/rev/964030fa5727 [2] https://dvcs.w3.org/hg/progress/raw-file/tip/Overview.html -- Jungkee Song Samsung Electronics
[xhr-1] Keep the responseType json
-Original Message- From: Jungkee Song [mailto:jungkee.s...@samsung.com] Sent: Wednesday, October 30, 2013 9:48 PM As planned, we editors prepared XMLHttpRequest Level 1 [1] as a Recommendation track version. Initially, we'd planned to put together a draft with only the parts that are *already compatibly* supported across the major implementations, but it turned out that most of the major features are showing *subtle differences* in behavior. Hence, we'd rather endeavored to secure wider test coverage [3] and analyzed the compatibility issues [4] (underway). From this point on, we plan to make efforts in resolving these compatibility issues and move the spec forward to LC(within this year)-CR-REC. The only features left out - due to lack of implementation or maturity - are: - data: URLs - responseType json Sorry for the confusion. As per our inspection, the responseType JSON should be kept in the Level 1 spec. The test of JSON http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/response-json. htm is buggy and will be fixed soon. Hallvord confirmed that it's supported in Firefox and will be in Blink in the very near future: http://code.google.com/p/chromium/issues/detail?id=119256. Refer to https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html and http://jungkees.github.io/XMLHttpRequest-test/ for the update ED and the interop status, respectively. For the editors, Jungkee - anonymous flag and XMLHttpRequestOptions dictionary For the bleeding-edge version [2], we need further discussion in direction as Anne recently revised the WHATWG spec [5] in terms of Fetch spec [6]. [1] https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html [2] https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html [3] http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/ [4] http://jungkees.github.io/XMLHttpRequest-test/ [5] http://xhr.spec.whatwg.org [6] http://fetch.spec.whatwg.org -- Jungkee Song
[xhr][xhr-1] status and plans
Hi, -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Thursday, October 03, 2013 1:40 AM I am also interested in the status and plans for both the version of XHR that is supposed to move to LC-CR-REC in 2013 and the XHR-Bleeding-Edge version. As planned, we editors prepared XMLHttpRequest Level 1 [1] as a Recommendation track version. Initially, we'd planned to put together a draft with only the parts that are *already compatibly* supported across the major implementations, but it turned out that most of the major features are showing *subtle differences* in behavior. Hence, we'd rather endeavored to secure wider test coverage [3] and analyzed the compatibility issues [4] (underway). From this point on, we plan to make efforts in resolving these compatibility issues and move the spec forward to LC(within this year)-CR-REC. The only features left out - due to lack of implementation or maturity - are: - data: URLs - responseType json - anonymous flag and XMLHttpRequestOptions dictionary For the bleeding-edge version [2], we need further discussion in direction as Anne recently revised the WHATWG spec [5] in terms of Fetch spec [6]. [1] https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html [2] https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html [3] http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/ [4] http://jungkees.github.io/XMLHttpRequest-test/ [5] http://xhr.spec.whatwg.org [6] http://fetch.spec.whatwg.org -- Jungkee Song
[XHR] request error distinction: abort and error
Hi, I would like to bring this topic back in the list: [XHR] remove user cancels request [1]. It was quite a controversial topic and as far as I recall the discussion was not clearly concluded. We've had three different error cases to distinguish: (A) Network initiated errors (B) abort() call (C) End user cancellation in the spec [2][3]: clicking on a stop button in browser chrome, hitting escape, page navigation and window.stop() [4] (A) and (B) are apparent; the question is whether (C) should be classified as a network error or an abort error? Here's the implementation status reported by @Yaffle. [5] I support treating (C) as abort error. Semantically (B) and (C) are aligned as behaviors to abort the request while (A) occurs when the request fails by *error*. I believe, for authors, the request error handlers for (B) and (C) have better chance to have the same code logic than that of (A) and (C). (I suppose the ways to distinguish between (B) and (C) are beyond the scope of XHR.) Accordingly, it'd be necessary to change the wordings as: (before) - If the end user cancels the request This is an abort error. (after) - If abort() method is invoked - If window.stop() is invoked - If the request cancellation is trigger by the end user This is an abort error. Note: The request cancellations by the end user include clicking on a stop button in browser chrome, hitting escape, page navigation, etc. WDYT? [1] http://www.w3.org/Search/Mail/Public/advanced_search?keywords=hdr-1-name=subjecthdr-1-query=%5BXHR%5D+remove+%22user+cancels+request%22hdr-2-name=fromhdr-2-query=hdr-3-name=message-idhdr-3-query=period_month=period_year=index-type=gindex-grp=Public__FULLtype-index=resultsperpage=20sortby=date [2] https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#infrastructure-for-the-send()-method [3] http://xhr.spec.whatwg.org/#infrastructure-for-the-send()-method [4] https://developer.mozilla.org/en-US/docs/Web/API/window.stop [5] https://github.com/w3c/web-platform-tests/issues/241#issuecomment-22750928 -- Jungkee Song
Re: [XHR] request error distinction: abort and error
On Sat, Aug 17, 2013 at 2:40 AM, Hallvord Steen hst...@mozilla.com wrote:
- If the request cancellation is trigger by the end user
This is an abort error.
Note: The request cancellations by the end user include clicking
on a stop button in browser chrome, hitting escape, page navigation, etc.
WDYT?
I think the real reason for the disagreement is that the feature lacks a
real, solid use case - except, perhaps, if a script wanted to do alert('Hi,
please stop clicking the Stop button while we\'re processing your order')
or something. There simply isn't much a script can sensibly do in response
to a user interruption (certainly when one isn't quite sure if it is the
user interrupting or not..)
However, what one might want to do is to re-schedule some request and try
again later. In this respect, I think a user cancellation is much closer to
a network error than an abort() call. If the network fails, you can assume
it's somewhat erratic and it makes sense to try in a minute. If the user
clicks stop, I guess you can also assume that the user is somewhat erratic
and it makes sense to try again later ;-)
In my understanding, here comes the difference. It seems network errors can
be considered erratic and it somehow makes sense to retry, but abort() call
and the user cancellations I referred to cannot simply be assured as
erratic situations. Users can explicitly abort the normal ongoing request
on purpose and in this case retry may not make sense. E.g. upon the request
abort made by clicking on browser stop button, the user rather expects to
explicitly reload or load the page again.
(99% of users won't really understand that they interrupted something, or
what they interrupted, especially since I believe browsers do not tend to
have stop UI for XHR traffic).
By that logic I think having it classified as an 'error' event is better,
but IMO this is a minor detail and not really worth our time..
-Hallvord
--
Jungkee Song
RE: [PE] Interop Status Update
-Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, July 01, 2013 7:20 AM On 6/27/13 1:05 AM, ext Jungkee Song wrote: Hi, I updated the Interop status of Progress Events: http://www.w3.org/wiki/Webapps/Interop/ProgressEvents Based on your updated data, it appears we have meet the CR exit criteria since every test now has at least two implementations that pass it. As such, it seems like we can start a CfC to publish a Proposed Recommendation. Chaals, All - do you agree? It may depend on the interpretation of the #1 condition of the CR exit criteria: http://www.w3.org/TR/2011/CR-progress-events-20110922/#crec Regarding the bugs filed with Blink, I've discussed with Kentaro Hara and Christophe Dumez about the possible timeline of the relevant patches. I thought things seemed to be optimistic (https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/47SxtdMBKc s), but the answer was it may be fixed by the end of this year as a few V8 APIs need to be added. With the current interop status and the implementation feedback, I would like to propose a CfC to publish PR at least. WDYT? Jungkee having two identical ongoing issues in Blink. FYI, I have not tested the WebKit nightly build yet. It would be appreciated if someone shares the result. To Microsoft team, Do you have any dev update in IE10 which brings any changes in the test result? It would indeed be good if we had more Passes. Can anyone from Opera indicate if the non-Passes for Presto will be fixed or not (and if so, when a public version will be available)? -ArtB Thanks and regards, Jungkee Jungkee Song Samsung Electronics
[PE] Interop Status Update
Hi, I updated the Interop status of Progress Events: http://www.w3.org/wiki/Webapps/Interop/ProgressEvents Firefox nightly 25.0a1 released on June 26 has passed all the tests. Thanks to Mozilla folks. Now we are getting close to CR-exit having two identical ongoing issues in Blink. FYI, I have not tested the WebKit nightly build yet. It would be appreciated if someone shares the result. To Microsoft team, Do you have any dev update in IE10 which brings any changes in the test result? Thanks and regards, Jungkee Jungkee Song Samsung Electronics
[XHR] readystatechange for multiple open calls
Hi Hallvord, While reviewing https://critic.hoppipolla.co.uk/r/86, I found the changed version assumes not firing readystatechange for the subsequent open() calls where the readyState is already 1, which in my understanding is not conformed to the current spec text. Commits are specifically: https://critic.hoppipolla.co.uk/a526c904?review=86 https://critic.hoppipolla.co.uk/89cc3591?review=86 I'll submit relevant issue comments right in Critics but in general do you see any issue with the readystatechange behavior with consecutive open() calls in the current spec text? Current browser implementations show: - Firefox fires. - Chrome and Opera do not. Jungkee Jungkee Song Samsung Electronics
RE: [XHR] readystatechange for multiple open calls
I just noticed that the topic has been discussed in another thread early this week. Sorry for rushing around after all that. BTW, what was the conclusion? -Original Message- From: Jungkee Song [mailto:jungkee.s...@samsung.com] Sent: Thursday, May 16, 2013 5:33 PM To: hallv...@opera.com; WebApps WG Subject: [XHR] readystatechange for multiple open calls Hi Hallvord, While reviewing https://critic.hoppipolla.co.uk/r/86, I found the changed version assumes not firing readystatechange for the subsequent open() calls where the readyState is already 1, which in my understanding is not conformed to the current spec text. Commits are specifically: https://critic.hoppipolla.co.uk/a526c904?review=86 https://critic.hoppipolla.co.uk/89cc3591?review=86 I'll submit relevant issue comments right in Critics but in general do you see any issue with the readystatechange behavior with consecutive open() calls in the current spec text? Current browser implementations show: - Firefox fires. - Chrome and Opera do not. Jungkee Jungkee Song Samsung Electronics
RE: RE: [XHR] readystatechange for multiple open calls
-Original Message- From: Hallvord Reiar Michaelsen Steen [mailto:hallv...@opera.com] Sent: Thursday, May 16, 2013 7:02 PM The conclusion is this commit: https://github.com/whatwg/xhr/commit/972797fb12106ca00292b9a2e2cb91d8766c4 640 The ED has been updated with the change: https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html which seems reasonable to me (but then, it aligns the spec with both old Opera and Chrome/Chromium/new Opera, so I'm sort of naturally biased to think it makes sense). It's *readystatechange* event. It is always the last open() the request actually takes the action on. Unless otherwise we would intend for authors to be notified every open() call, the change seems reasonable to me, too. Also, kudos for reviewing the test changes so closely that you pointed out this issue and it's non-alignment with the spec as it was without being aware of the discussion. :-) -- Hallvord R. M. Steen Core tester, Opera Software
[XHR.Bleeding-edge] ED update
Hi, I just updated ED with WHATWG changes: https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html We are now mostly in sync with the WHATWG version. Here's the changelog: https://dvcs.w3.org/hg/xhr/log Please reply if you find any issues with the applied changes. Jungkee Jungkee Song Samsung Electronics
Re: [admin] Call for Agenda topics for April 25-26 f2f meeting
Hi Art, Sorry for the late response. Regarding the F2F agenda, I would like to add Progress Events and XMLHttpRequest in 16:00 to 17:00 time slot in 25th. it's been hard for the co-editors to remotely join the discussion, but a thing is if Anne is planning to remotely join the discussion, the time is quite late in Europe. Sorry for that. I suppose 20 min for Progress Evnets and 40 min for XHR would be enough. See you tomorrow! Jungkee On Thu, Feb 7, 2013 at 7:02 AM, Arthur Barstow art.bars...@nokia.comwrote: Hi All, We created an agenda page for WebApps' April 25-26 f2f meeting, hosted by eBay in San Jose CA US [Agenda]. The proposed meeting format is similar to our previous f2f meetings - a mix of preassigned time slots for some specific topics use an `unconference` style meeting to determine the remainder of agenda topics, based on participants' interest(s). Comments regarding this format are welcome. As previously done, we seeded the agenda with some potential topics and we will update that set accordingly. Proposals for other topics are of course welcome - either in reply to this e-mail or via direct edits of the agenda page. We plan to use the W3C's phone conference bridge if there are remote participants that want to join some part of the meeting. Preregistration for the meeting is required and we will announce the registration page when it is available. FYI, the HTMLWG and WAI PF WG will have co-located f2f meetings that week (see [HTMLWG-Agenda]). -Regards, Art and Chaals [Agenda] [HTMLWG-Agenda] http://www.w3.org/wiki/HTML/**wg/2013-04-Agendahttp://www.w3.org/wiki/HTML/wg/2013-04-Agenda -- Jungkee Song
RE: [XHR] remove user cancels request
From: Timmy Willison [mailto:timmywill...@gmail.com] Sent: Monday, February 25, 2013 2:55 AM On Feb 24, 2013, at 11:18 AM, Glenn Maynard gl...@zewt.org wrote: On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote: Currently the XMLHttpRequest Standard special cases the condition where the end user terminates the request. Given that there's less and less likely to be UI for that kind of feature, does it still make sense to expose this distinction from a network error in the API? I think we should merge them. http://xhr.spec.whatwg.org/ I didn't even know about that behavior. I've always assumed that the only way onabort happens is as a result of my calling abort(). I don't think breaking that assumption would break my code, but it's a rare, untested code path. I doubt other developers test it either. I agree that users killing a network request should look like a network error, and in general the API should guarantee that onabort is only fired as a result of a call to abort(). According to the current spec, it is already the case that onabort() is called only when client.abort() is explicitly called (including CORS requests.) onerror() is getting called in actual network errors such as DNS error, TLS negotiation failure, cross-origin access violation, etc. I am not sure what conditions Anne exactly propose to remove from the spec. I can think of only three scenarios where the end user *terminates* the request: calling open(), calling abort() or explicitly stop in browser chrome. I don't think client.open() and explicit browser stop are what Anne is talking about. Anne, could you elaborate what part of the text are you pointing? If it's the case that you want to merge abort into error, I tend to disagree as there can be use cases explicitly putting cancel button in UI that should be distinguished from network initiated errors. Jungkee +1 -- Glenn Maynard - Timmy
RE: Declarative invocation and progressing Web Intents
+1 Regards, Jungkee 2013. 1. 23. 오후 9:38에 Nilsson, Claes1 claes1.nils...@sonymobile.com님이 작성: +1 ** ** *From:* frederick.hir...@nokia.com [mailto:frederick.hir...@nokia.com] *Sent:* den 22 januari 2013 21:14 *To:* freda...@live.com *Cc:* frederick.hir...@nokia.com; public-...@w3.org; public-web-inte...@w3.org; public-webapps@w3.org; d...@w3.org *Subject:* Declarative invocation and progressing Web Intents ** ** Fred ** ** I object to this being a resolution, since I never saw a formal Call for Consensus sent to the WebIntents list. I saw an informal discussion of ideas and an offer to provide proposals, not a proposal to change where standards are delivered. I know the DAP WG has not had a chance to discuss or agree to this resolution. ** ** In addition, currently members of DAP have work items to progress both Web Intents and Web Activities and we have not stopped this work - though we need to review the status. ** ** I also am not clear on the IPR implications of work being done in the PUA CG versus/with a working group. ** ** I suggest a change to what you propose. I would like to suggest that the PUA CG consider Declarative Invocation in cooperation with the WebIntents Task Force, and provide input regarding Web Intents development, but not take over development of this standardization. I suggest the standard remain a joint deliverable from DAP (and WebApps) WGs as joint deliverables until we formally decide otherwise. ** ** I think first steps for declarative invocation, however, might be documenting use cases and requirements. ** ** What do others think? ** ** Thanks ** ** regards, Frederick ** ** Frederick Hirsch, Nokia Chair, W3C DAP Working Group ** ** ** ** ** ** On Jan 21, 2013, at 7:15 PM, ext Fred Andrews wrote: Given that there have been no objections, the PUA CG accepts the development of the 'Declarative Invocation' standard. This technology has great potential for securing the users private UA state and is well aligned with the charter of the PUA CG. Given that this will likely require a rewrite of the Web Intents proposal the PUA CG will also take over the development of a suitable replacement. Members of the Web Intents Task Force are invited to join the PUA CG for further discussions. cheer Fred Chair Private User Agent Community Group -- From: freda...@live.com To: jhawk...@google.com CC: public-web-inte...@w3.org; public-...@w3.org Date: Wed, 9 Jan 2013 03:19:31 + Subject: RE: Declarative invocation Dear James, The declarative invocation markup would ideally support multiple inputs from a webpage and multiple outputs back to the webpage. There might be multiple intents supported on a page, and perhaps there might even be overlap between the inputs and outputs. For example, a file input element could declare the mime type(s) accepted, and this could be used with a pick intent to return a blob (single output). This blob might be then be usable as a further input to an 'image edit' intent that returns an updated blob (single input, single output). Finally when the input form is submitted the blob is sent. This could allow a webpage without JS enabled to upload an edited image captured from a device camera, all from within the web browser. The user can use trusted web apps for the image capture and for the image editing without exposing the camera API and without sharing UA state via an image editing web app. For example, a section of an input form with contact inputs (name, address, etc), could be used with an intent that can search a trusted 'contacts' web app using supplied fields to direct the search and returning the requested fields that are used to populate the input form (multiple input, multiple output). The user might make some changes to the address and invoke another web intent to save the new contact address (multiple input, no output?). There may be some opportunity to coordinate the required markup with general 'semantic web' markup, such a microdata. The web browser could then implement the UI and invocation without the webpage needing to add the UI support, and this might be done in a manner that is less vulnerable to spoofing. I would also be keen to explore how this could help accessibility of webpage input forms. For example, a photo viewing webpage might markup a slideshow allowing a presentation web app, that is specifically adapted to a limited device, to show the slide show and this could be invoked via a web intent (multiple input, no output). The direction to take with the webpage UI support for invoking web intents is not clear to me yet. It would be good to support buttons that can invoke an intent, such as a 'share' intent button, and this would allow a webpage to voluntarily place and style
Re: RfR: Progress Events Test Cases; deadline January 28
On Sat, Jan 19, 2013 at 6:38 PM, Anne van Kesteren ann...@annevk.nl wrote: http://w3c-test.org/webapps/ProgressEvents/tests/submissions/Samsung/ These are testing XMLHttpRequest. There are no normative criteria in the Progress Events specification that justify these tests. I agree. It seems that .../submissions/Ms2ger test cases cover all the normative criteria of Progress Events spec. Then, we can adjust the scope of the RfR to Ms2ger's contribution. (I will fix the issue in .../submissions/Samsung anyway.) (This in part is why I merged Progress Events into XMLHttpRequest. On its own it's kinda useless.) I believe Progress Events spec has a meaning as an event interface definition itself as long as it would potentially support multiple use cases (currently XHR and img element.) As for the tests, one is buggy because the PHP gives a 404. I've pushed the php file in http://dvcs.w3.org/webapps/ProgressEvents/tests/submissions/Samsung/resources/ but cannot find it at w3-test.org mirror. Can anyone help? Another one assumes the network is not slow by checking for ev.loaded != 0. Fixed. https://dvcs.w3.org/hg/webapps/rev/52b745cebe4f Thanks for comments. Jungkee -- http://annevankesteren.nl/ -- - Jungkee Song Samsung Electronics
Re: RfR: Progress Events Test Cases; deadline January 28
2013. 1. 20. 오전 12:39에 Arthur Barstow art.bars...@nokia.com님이 작성: On 1/19/13 10:20 AM, ext Jungkee Song wrote: I've pushed the php file in http://dvcs.w3.org/webapps/ProgressEvents/tests/submissions/Samsung/resources/ but cannot find it at w3-test.org mirror. Can anyone help? Did you do a `hg push`? It appears not https://dvcs.w3.org/hg/webapps/summary. Yes, I did. The php file is included in this changeset: https://dvcs.w3.org/hg/webapps/rev/ec95ece1bbf8 Thanks. Jungkee
Re: CfC: publish WD of XHR; deadline November 29
On Sun, Dec 2, 2012 at 11:07 AM, James Robinson jam...@google.com wrote: Sure there is if the W3C version is stale, as is the case here. I don't think it's a technical issue to discuss. There should be corresponding publication rules. Art, Charles, Doug, Can you help clarifying which links we have to use? In the proposed version, I've changed the links to the following specs: - [CORS], [DOM], [DOMPS], [HTML] from the WHATWG version to the latest W3C TR doc. - [FILEAPI], [PROGRESSEVENTS], [WEBIDL] from the latest W3C ED to the latest W3C TR doc. That commit replaced a link to http://xhr.spec.whatwg.org/, last updated roughly a week ago, with a link to http://www.w3.org/TR/XMLHttpRequest/ which is dated January 17th and is missing an entire section (section 6). This change does not affect any links in the result doc, and in fact this proposed publication will reduce the gap. The proposed WD is aligned with the WHATWG version except: - Progress Events is not merged but staying as a separate spec. - Streams API is deferred to next version. - The last three commits (Nov 22) in WHATWG has not been incorporated yet. Jungkee It also replaced a link to http://fetch.spec.whatwg.org/# with http://www.w3.org/TR/cors/# which is similarly out of date by the better part of a year and lacking handling for some HTTP status codes. Every single reference updated in this commit changed the document to point to an out-of-date and less valuable resource. It seems that you, like the author of the commit message, mistakenly think it's a goal to replace all links to point to W3C resources even when they are strictly worse. That's not in the W3C pub rules or a good idea. - James
RE: CfC: publish WD of XHR; deadline November 29
From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, November 26, 2012 9:46 PM On 11/26/12 1:38 AM, ext Jungkee Song wrote: I suggest we put the following wordings for Anne's work and WHATWG to be credited. If we make consensus, let me use this content for publishing the WD. Please put your proposed text in a version of the spec we can review and send us the URL of that version. Please find the version at: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html Jungkee
RE: CfC: publish WD of XHR; deadline November 29
From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Tuesday, November 27, 2012 3:05 AM I think the next step is for the XHR Editors to create a TR version using the WD template so that everyone can see exactly what is being proposed for publication as a TR. Please create that version as soon as you can so that this CfC can be based on that version (rather than the ED) and reply with the URL of the TR version. (Please use 6 December 2012 as the publication date.) We prepared a proposed TR version at: http://dvcs.w3.org/hg/xhr/raw-file/tip/TR/Overview.html Thank you. Jungkee -Thanks, AB
RE: CfC: publish WD of XHR; deadline November 29
Hi, I suggest we put the following wordings for Anne's work and WHATWG to be credited. If we make consensus, let me use this content for publishing the WD. As the co-Editors of W3C XHR spec wrote in the threads, we have our role and contribution in moving this spec toward the W3C REC. Up to the moment, we mostly had to take care of the gaps between W3C version and WHATWG version to make them convergent. We will try to make more productive discussions along the way from this point on. [Status of this Document] This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/. If you wish to make comments regarding this document in a manner that is tracked by the W3C, please submit them via using our public bug database ( https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG), or please send comments to public-webapps@w3.org (archived) with [XHR] at the start of the subject line. The bulk of the text of this specification is also available in the WHATWG *XMLHttpRequest Living Standard (link to the whatwg spec)*, under a license that permits reuse of the specification text. *The W3C Web Applications Working Group is the W3C working group responsible for this specification's progress along the W3C Recommendation track.* This specification is the 22 November 2012 Editor's Draft. Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. *Work on this specification is also done at the WHATWG. The W3C Web Applications working group actively pursues convergence of XMLHttpRequest specification with the WHATWG.* This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy. This document supersedes XMLHttpRequest 1. [Acknowledgments] +Special thanks to Anne van Kesteren who has provided nearly all the contents until he stepped down as a W3C editor and is now in succession providing discussions and contents as the editor of the XMLHttpRequest Living Standard in WHATWG which this version of the specification pursues convergence. Jungkee -Original Message- From: Kang-Hao (Kenny) Lu [mailto:kangh...@oupeng.com] Sent: Saturday, November 24, 2012 2:44 AM To: WebApps WG Subject: Re: CfC: publish WD of XHR; deadline November 29 (12/11/24 1:28), Adam Barth wrote: Now, that being said and seeing as we cannot put Anne as an editor of the W3C version of the spec (because, technically, he's not). How do you guys suggest we go about acknowledging the WHATWG source? Where in the spec? How? With what kind of wording? I would recommend acknowledging the WHATWG upfront in the Status of this Document. The document currently reads: ---8--- This document is produced by the Web Applications (WebApps) Working Group. The WebApps Working Group is part of the Rich Web Clients Activity in the W3C Interaction Domain. ---8--- Just in case folks don't know. HTML5 also has a paragraph like this in the Status of this Document: # The bulk of the text of this specification is also available in the # WHATWG HTML Living Standard, under a license that permits reuse of # the specification text. Another possibility is to say something like | Anne van Kesteran authored most of the text in the spec. in the Acknowledgment section. I'd note that in CSS specs an Acknowledgment section is not always just a list of names and so suppose this is doable. I'm not pushing for this though, as I find this quite obvious. Perhaps Anne would be willing to suggest some text that he would find appropriate? +1, or perhaps Anne would like to object to this CfC no matter what? Cheers, Kenny -- Web Specialist, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/
[PE] interface MessageEvent : ProgressEvent
Hi,
While mulling over the usage of PE event, I came up with a suggestion. As the
data attribute of message event delivers structured objects including File Blob
and ArrayBuffer objects, authors might need a primitive way of checking the
progress of message load.
I think the MessageEvent interface derived from ProgressEvent interface would
solve many such use cases. It seems we already have candidates: server-sent
events, web socket, cross-document messaging, channel messaging, web worker.
WDYT?
[Constructor(DOMString type, optional MessageEventInit eventInitDict)]
interface MessageEvent : ProgressEvent {
readonly attribute any data;
readonly attribute DOMString origin;
readonly attribute DOMString lastEventId;
readonly attribute (WindowProxy or MessagePort)? source;
readonly attribute MessagePort[]? ports;
};
Jungkee
-Original Message-
From: Jungkee Song [mailto:jungkee.s...@samsung.com]
Sent: Friday, November 16, 2012 11:53 AM
To: public-webapps@w3.org
Subject: [PE] Start working on Progress Events
Hi all,
I came to start working on Progress Events spec to move it towards REC.
Because the spec is already a CR, I am planning to focus on satisfying the
exit criteria to ship it. Please see inline comments and questions.
Jungkee
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Thursday, November 15, 2012 10:51 PM
On 11/15/12 3:11 AM, ext Jungkee Song wrote:
Hi Art, Charles and Anne,
At this stage, it will be of great help if you give me some comments
on
any issues, concerns, expected actions, etc.
Since the spec is already a CR (with exit criteria
http://www.w3.org/TR/2011/CR-progress-events-20110922/#crec), some
questions ...
* Are there any significant differences between the CR and Anne's WHATWG
spec? If yes, what are they and should they postponed to v.next?
As I've gone through it, there's no significant change. There are only a
few minor ones including term (octets to bytes) and xref (to event
definition) things.
* What is the implementation status of the CR? Are there at least two
independent implementations that can be tested?
This is my question at the moment. Can anyone share implementation data
for this spec?
* Are the tests in the test suite sufficient to test the CR
http://w3c-test.org/webapps/ProgressEvents/tests/submissions/Ms2ger/?
If not, what is the plan to fill the gaps?
I will scope it out.
BTW, I have a relatively strong preference to have this conversation on
public-webapps so please feel free to copy any part of what I say above
to that list.
-Thanks, Art
[PE] Start working on Progress Events
Hi all, I came to start working on Progress Events spec to move it towards REC. Because the spec is already a CR, I am planning to focus on satisfying the exit criteria to ship it. Please see inline comments and questions. Jungkee From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Thursday, November 15, 2012 10:51 PM On 11/15/12 3:11 AM, ext Jungkee Song wrote: Hi Art, Charles and Anne, At this stage, it will be of great help if you give me some comments on any issues, concerns, expected actions, etc. Since the spec is already a CR (with exit criteria http://www.w3.org/TR/2011/CR-progress-events-20110922/#crec), some questions ... * Are there any significant differences between the CR and Anne's WHATWG spec? If yes, what are they and should they postponed to v.next? As I've gone through it, there's no significant change. There are only a few minor ones including term (octets to bytes) and xref (to event definition) things. * What is the implementation status of the CR? Are there at least two independent implementations that can be tested? This is my question at the moment. Can anyone share implementation data for this spec? * Are the tests in the test suite sufficient to test the CR http://w3c-test.org/webapps/ProgressEvents/tests/submissions/Ms2ger/? If not, what is the plan to fill the gaps? I will scope it out. BTW, I have a relatively strong preference to have this conversation on public-webapps so please feel free to copy any part of what I say above to that list. -Thanks, Art
[XHR] ED update
Hi all,
I've pushed an updated ED [1] in which we editors incorporated Anne's
changes (up to Sep) based upon the discussion in the F2F in Lyon. Here's the
list of changes:
http://dvcs.w3.org/hg/xhr
Most notably,
- the constructor AnonXMLHttpRequest() has been removed and replaced by
using dictionary XMLHttpRequestOptions. i.e., client = new
XMLHttpRequest({anon:true});
- made data scheme work in the send() method
- embraced the Encoding Standard
We will cover the Oct and Nov changes while making progress in the testing
side as well. As Julian introduced at the F2F in Lyon, the ED contains
annotation for test coverage now.
[1] http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html
Jungkee
Jungkee Song
Samsung Electronics
RE: RE: [XHR] Open issue: allow setting User-Agent?
-Original Message- From: Hallvord Reiar Michaelsen Steen [mailto:hallv...@opera.com] Sent: Wednesday, October 17, 2012 3:50 PM The point is that a browser can act as if every single server response included Vary: User-Agent. And perhaps should. Intermediary caches _certainly_ should. Good suggestion. But my concern was even if browser acts as such, intermediary caches would still return forged content in its cache rather than trying to make a fresh request to origin server. That is, authors would expect that they are free from cache poisoning threat based off of the spec, but it might not be true when caching proxy is involved. Unless server itself actually puts Vary: User-Agent in the response, we cannot entirely avoid the cache poisoning scenario. Jungkee Julian Aubourg wrote; I'm still more concerned about potentially legitimate use cases of User-Agent filtering that could lead to security breaches when removing User-Agent from the non-modifiable list. But if no-one else feels like there could ever be such a legitimate use-case So far we haven't heard from anyone who has seen or implemented such a solution in real life ;-). Neither do I disagree to take User-Agent header out of the non- modifiable list as far as we resolve the possible issues. Before we make decision, I would like to bring some other issues found in an article [1]: (quoted from [1]) A few of the problems include: 1. Many websites will return only error pages upon receiving a UA header over a fixed length (often 256 characters). Should we specify the length of the header that the script allows in the spec? I think the spec should try to allow JS authors to work around buggy servers rather than attempting to work around server bugs ourselves. This may be a general issue with header lengths, though, just seen more frequently with User-Agent because of all the junk some setups add to it, but I don't think it makes sense to mandate that second argument to setRequestHeader() must be less than 256 characters. If anything, this makes it more useful to be able to set User-Agent - if you're writing an app for users with lots of junk in the UA string and want to load data from a server that can't handle that ;-) 2. In IE7 and below, if the UA string grows to over 260 characters, the navigator.userAgent property is incorrectly computed. IE specific case. I don't think we will change the navigator.userAgent with XHR request. Correct. This doesn't apply. 3. Poorly designed UA-sniffing code may be confused and misinterpret tokens in the UA. Sanitizing the header value could be considered. We could, but figuring out some sensible rules that will handle the world wild web's poorly designed sniffing would take us a while ;-) 4. Poorly designed browser add-ons are known to misinterpret how the registry keys are used, and shove an entire UA string into one of the tokens, resulting in a nested UA string. This problem doesn't apply to us. 5. Because UA strings are sent for every HTTP request, they entail a significant performance cost. In degenerate cases [2], sending the UA string might consume 50% of the overall request bandwidth. Also something that's probably best left to the JS author's unpredictable needs IMO. -Hallvord [1] http://blogs.msdn.com/b/ieinternals/archive/2009/10/08/extending-the- user-ag ent-string-problems-and-alternatives.aspx [2] http://brianary.blogspot.com/2009/07/internet-explorer-user-agent- spam.html Jungkee -- Hallvord R. M. Steen Core tester, Opera Software
RE: [XHR] Open issue: allow setting User-Agent?
-Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Wednesday, October 17, 2012 2:09 AM On 10/16/12 1:04 PM, Mark Baker wrote: That would be an improvement, but wouldn't solve the problem of intermediary cache poisoning. Ah, yes. Intermediary caches are indeed a problem. I don't see anything the browser can do to solve that problem, unfortunately. On the other hand, caches that don't assume Vary: User-Agent are already completely broken on the web when they sit between multiple users using multiple browsers and the rest of the web Julian Aubourg wrote; Couldn't we simply state in the spec that browsers must add the User- Agent header to the Vary list, all the time? Vary is a response header, set by the server. The point is that a browser can act as if every single server response included Vary: User-Agent. And perhaps should. Intermediary caches _certainly_ should. Yes, that could solve the issue, but it seems we cannot avoid the intermediary caching proxy problem unless server actually put Vary: User-Agent in every response. I'm wondering if it's still worth to put it into spec. Julian Aubourg wrote; I'm still more concerned about potentially legitimate use cases of User-Agent filtering that could lead to security breaches when removing User-Agent from the non-modifiable list. But if no-one else feels like there could ever be such a legitimate use-case, then I don't think we should hold back because of this out-of-cache XSS attack: let's just specify User-Agent has to be in Vary all the time. It's not like it will break caching in the general case anyway. Neither do I disagree to take User-Agent header out of the non-modifiable list as far as we resolve the possible issues. Before we make decision, I would like to bring some other issues found in an article [1]: (quoted from [1]) A few of the problems include: 1. Many websites will return only error pages upon receiving a UA header over a fixed length (often 256 characters). Should we specify the length of the header that the script allows in the spec? 2. In IE7 and below, if the UA string grows to over 260 characters, the navigator.userAgent property is incorrectly computed. IE specific case. I don't think we will change the navigator.userAgent with XHR request. 3. Poorly designed UA-sniffing code may be confused and misinterpret tokens in the UA. Sanitizing the header value could be considered. 4. Poorly designed browser add-ons are known to misinterpret how the registry keys are used, and shove an entire UA string into one of the tokens, resulting in a nested UA string. 5. Because UA strings are sent for every HTTP request, they entail a significant performance cost. In degenerate cases [2], sending the UA string might consume 50% of the overall request bandwidth. [1] http://blogs.msdn.com/b/ieinternals/archive/2009/10/08/extending-the-user-ag ent-string-problems-and-alternatives.aspx [2] http://brianary.blogspot.com/2009/07/internet-explorer-user-agent-spam.html Jungkee
RE: [XHR] Open issue: allow setting User-Agent?
-Original Message-
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Sent: Sunday, October 14, 2012 12:49 AM
On 10/13/12 5:08 AM, Hallvord R. M. Steen wrote:
I came across an article [1] that describes some of the reasoning for
Flash's change in security policy when it banned setting User-Agent.
Apparently, some sites echo the User-Agent value back in markup in
certain contexts (maybe a browser requirements page for example).
And naturally do not send Vary: User-Agent?
I'm not sure what Hallvord assumed here, but if certain backend intends to
provide its content under some browser requirements, isn't Vary: User-Agent
sort of a required header to have related caching proxy, if any, work
correctly? Otherwise, subsequent requests on the same resource with different
User-Agent string would be regarded as a cache HIT in caching proxy anyway.
Anyway, the point here is that if changing of User-Agent is allowed in script,
it will be possible for malicious third party to set arbitrary User-Agent
strings in generating XSS attacks.
To which Hallvord wrote:
So it seems reasonable to keep the limitation on setting User-Agent.
+1.
(I'm still wondering if we could lift it only for the cross-domain case
where the target site must opt in to receiving a changed UA string though..)
-1. I don't know if there can be any smart way, but as of now I don't think it
is a good way to determine the availability of setRequestHeader('User-Agent',
...) depending on the choice of certain backend.
Jungkee
However, another threat might be using an XHR request to put a
generated page with injected content in the browser's cache, then
opening the page directly in a new window. The page would likely be
taken from cache
This seems simple enough to deal with on the browser side: Assume Vary:
User-Agent on all requests. Probably a good idea anyway.
-Boris
RE: [XHR] Open issue: allow setting User-Agent?
-Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Monday, October 15, 2012 9:50 PM On 10/15/12 7:18 AM, Jungkee Song wrote: but if certain backend intends to provide its content under some browser requirements, isn't Vary: User-Agent sort of a required header to have related caching proxy, if any, work correctly? Yes, it is, but it's rare for websites to think about that sort of thing in my experience. In particular, I have yet to encounter a site that both does server-side UA sniffing _and_ sends Vary: User-Agent. Yes, I think it's very rare. I found that a Korean web portal site, Naver, does send Vary:Accept-Encoding,User-Agent upon the request to http://www.naver.com; and http://m.naver.com;, though. Otherwise, subsequent requests on the same resource with different User- Agent string would be regarded as a cache HIT in caching proxy anyway. Indeed. Anyway, the point here is that if changing of User-Agent is allowed in script, it will be possible for malicious third party to set arbitrary User-Agent strings in generating XSS attacks. While true, a third party can already do this with things like botnets, no? I'm not sure I see the additional threats here. Can you explain? From that perspective, I don't think setting the User-Agent string in script poses any unknown treats. However, it seems like we are permitting another choice which is simply calling a JavaScript function. FYI, here is another article [1] written about the compatibility problem on changing the UA string at runtime. [1] http://blogs.msdn.com/b/ieinternals/archive/2009/10/08/extending-the-user-agent-string-problems-and-alternatives.aspx Jungkee
RE: [XHR] Open issue: allow setting User-Agent?
I don't think it is a right and wrong discussion. There's valid rationale for
both pros and cons.
Having mulled it over, I am leaning to not removing User-Agent from the list of
prohibited headers at least in the current version. I admit that the use case
is compelling to certain group of authors (mainly testing and analyzing
purpose) but don't think it acquires consensus for the whole web. Besides, IMO
browser spoofing either through the browser's main HTTP request or XHR request
is not the ultimate way to handle the browser sniffing issues in practical
service scenarios.
Jungkee
-Original Message-
From: Hallvord R. M. Steen [mailto:hallv...@opera.com]
Sent: Wednesday, October 10, 2012 12:34 AM
To: Julian Aubourg; annevankeste...@gmail.com
Cc: Anne van Kesteren; Jungkee Song; public-webapps@w3.org
Subject: Re: [XHR] Open issue: allow setting User-Agent?
Julian Aubourg j...@ubourg.net skreiv Tue, 09 Oct 2012 16:34:08 +0200
I've had trouble writing extensions and user scripts to work around
backend sniffing, due to being unable to simply set User-Agent for a
specific script-initiated request and get the correct content. As
I've
attempted to explain to Anne, I think this experience is relevant to
scripts using CORS, because they also want to interact with backends
the
script author(s) don't choose or control.
If the backend sniffs out (all or some) browsers, it's the backend's
choice.
We end up in a philosophical disagreement here :-) I'd say that whatever
browser the user decides to use is the user's choice and the server should
respect that.
CORS has been specified so that you NEED a cooperative backend.
Unlock a header and some other means to sniff you out will be found and
used :/
Anne van Kesteren also makes a similar point, so I'll respond to both:
If you consider CORS you also need to consider that if we allow
developers to set user-agent a preflight request would be required for
that header (and the server would need to allow it to be custom). So
it's not quite that simple and would not actually help.
One word: legacy. For example Amazon.com might want to enable CORS for
some of its content. The team that will do that won't necessarily have any
intention of blocking browsers, but will very likely be unaware of the
widespread browser sniffing in other parts of the Amazon backend. (With
sites of Amazon's or eBay's scale, there is in my experience simply no
single person who is aware of all browser detection and policies). Hence,
there is IMO non-negligible risk that a large web service will be
cooperative on CORS but still shoot itself in the foot with browser
sniffing.
If I write, say, a CORS content aggregator, I would want it to run in all
browsers, not only those allowed by the content providers. And I'd want to
be in control of that. Hence, in my view this issue is mostly a trade-off
between something script authors may need and more theoretical purity
concerns.
The changed User-Agent will of course only be sent with the requests
initiated by the script, all other requests sent from the browser will
be normal. Hence, the information loss will IMO be minimal and probably
have no real-world impact on browser stats.
var XHR = window.XMLHttpRequest;
window.XMLHttpRequest = function() {
var xhr = new XHR(),
send = xhr.send;
xhr.send = function() {
xhr.setRequestHeader( User-Agent, OHHAI! );
return send.apply( this, arguments );
};
return xhr;
};
Yes, this could give a generic library like jQuery less control of the
contents of *its* request. However, there will still be plenty of requests
not sent through XHR - the browser's main GET or POST for the actual page
contents, all external files loaded with SCRIPT, LINK, IMG, IFRAME, EMBED
or OBJECT, all images from CSS styling etc. Hence I still believe the
information loss and effect on stats will be minimal.
Also, the above could be a feature if I'm working on extending a site
where I don't actually fully control the backend - think a CMS I'm forced
to use and have to work around bugs in even if that means messing with how
jQuery sends its requests ;-).
If your backend really relies on User-Agent header values to avoid
being
tricked into malicious operations you should take your site offline
for a
while and fix that ;-). Any malicious Perl/PHP/Ruby/Shell script a
hacker
or script kiddie might try to use against your site can already fake
User-Agent
Oh, I agree entirely. Except checking User-Agent is a quick and painless
means to protect against malicious JavaScript scripts. I don't like the
approach more than you do, but we both know it's used in the wild.
I'm afraid I don't know how this is used in the wild and don't fully
understand your concerns. Unless you mean we should protect dodgy SEO
tactics sending full site contents to Google bot UAs
RE: [WEBIDL] nullable dictionary members
Thanks for the comment, Boris!
Jungkee
-Original Message-
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Sent: Thursday, August 16, 2012 3:26 PM
To: public-webapps@w3.org
Subject: Re: [WEBIDL] nullable dictionary members
On 8/15/12 10:05 PM, Jungkee Song wrote:
Having said that dictionary members are inherently optional by
definition,
is it meaningful (and valid) to mark optional fields as nullable?
Seems like it should be to me, yes.
dicationary Foo {
DOMString iWantToBeRequired = Default;
DOMString? iWantToBeNullable;
DOMString iAmAlreadyOptional;
};
Do the two dictionary members iWantToBeNullable and
iAmAlreadyOptional
semantically make any difference?
Yes. The latter can either be unset or set to a string. The former can
be unset, set to a string, or set to null. Those are different things.
I was thinking spec writers sometimes encounter situations where they
would
like to explicitly describe certain dictionary members are required
while
others are not.
Dictionaries can't have a required member via IDL, unless the member has
a default value
Of course the prose can always call for throwing if a member is not set.
-Boris
[WEBIDL] nullable dictionary members
Hi Cameron,
I have a question about the use of *nullable* type for dictionary
definition.
Having said that dictionary members are inherently optional by definition,
is it meaningful (and valid) to mark optional fields as nullable?
For example,
dicationary Foo {
DOMString iWantToBeRequired = Default;
DOMString? iWantToBeNullable;
DOMString iAmAlreadyOptional;
};
Do the two dictionary members iWantToBeNullable and iAmAlreadyOptional
semantically make any difference?
I was thinking spec writers sometimes encounter situations where they would
like to explicitly describe certain dictionary members are required while
others are not.
Regards,
Jungkee
Jungkee Song
Samsung Electronics
[WEBIDL] nullable dictionary
Hi Cameron, While reading about dictionary from your Web IDL (Second Edition) draft, I found a part that needs clarification: -8- 3.3 Dictionaries If the Type is an identifier or an identifier followed by ?, then the identifier must identify an interface, *dictionary*, enumeration, callback function or typedef. -8- The spec allows dictionary type to go nullable here. -8- 3.10.22 Nullable types The inner type must not be any, a *dictionary* type, another nullable type, or a union type that itself has includes a nullable type or has a dictionary type as one of its flattened member types. -8- It does not allow nullable here. From the mail history I looked up, the intention is to not allow nullable dictionary type any more. It that right? Regards, Jungkee Jungkee Song Samsung Electronics
RE: Lazy Blob
Hi Glenn,
var xhr = new XMLHttpRequest();
xhr.open(GET, resource.jpg);
var urlObject = xhr.getURLObject();
var newURL = URL.getObjectURL(urlObject);
img.src = newURL;
It's neat and I like the idea, too. However, there is a reason that I prefer
our blob approaches:
=== Another XHR Approach
partial interface XMLHttpRequest {
Blob makeLazyBlob ();
};
Usage:
[Service]
var xhr = new XMLHttpRequest();
xhr.open(GET, /kitten.png, true);
xhr.setRequestHeader(Authorization, Basic DEADBEEF);
var blob =xhr.makeLazyBlob();
window.intent.postResult(blob);
From totally client developer's point of view, who perhaps do not care the
underlying details at all, it is absolutely transparent to use the obtained
blob as they used to deal with. (no matter which type of data the blob
contains)
[Client]
navigator.startActivity(intent, resultOK);
function resultOK (data) {
// *data* is a blob delivered by service end.
it can be a few MB of image file (kitten.png in the above example)
or a few MB of mp3 music file
or a few MB of raw text file
or a huge binary string
etc.
var blob = data;
var reader = new FileReader();
// developers have all the existing file reader options with no
additional concern such that they do any further operations with the result
reader.readAsDataURL(blob);
// or
reader.readAsBinaryString(blob);
// or
reader.readAsText(blob);
// or
reader.readAsArrayBuffer(blob);
}
Regards,
Jungkee
Jungkee Song
Samsung Electronics
RE: Lazy Blob
- URLObject represents a resource that can be fetched, FileReader'd, createObjectURL'd, and cloned, but without any knowledge of the contents (no size attribute, no type attribute) and no slice() as URLObjects may not be seekable. - Blob extends URLObject, adding size, type, slice(), and the notion of representing an immutable piece of data (URLObject might return different data on different reads; Blob can not). +1 from me on this one. +1. I get a sense that this could possibly be a consensus position (or at least I'm going to claim that it is so as to get disagreement to manifest). Assuming it is, the next steps are: . Having agreed on a solution, do we agree on the problem? (i.e. would this get implemented?) . If so, we can bake this as a standalone delta spec but it would make more sense to me to make the changes directly to the relevant specs, namely FileAPI and XHR. I've copied Anne, Arun, and Jonas - any thought? In either case, I'm happy to provide the content. Having hammered out a consensus, I would like to contribute to providing the content. Jungkee Jungkee Song Samsung Electronics
RE: Lazy Blob
Hi Glenn and all,
From: Glenn Maynard [mailto:gl...@zewt.org]
Sent: Thursday, August 02, 2012 12:45 AM
To: Robin Berjon
Cc: WebApps WG; Jungkee Song
Subject: Re: Lazy Blob
On Wed, Aug 1, 2012 at 9:59 AM, Robin Berjon ro...@berjon.com wrote:
var bb = new BlobBuilder()
, blob = bb.getBlobFromURL(http://specifiction.com/kitten.png;, GET, {
Authorization: Basic DEADBEEF });
Everything is the same as the previous version but the method and some
headers can be set by enumerating the Object. I *think* that those are all
that would ever be needed.
We already have an API to allow scripts to make network requests: XHR.
Please don't create a new API that will end up duplicating all of that.
However this might be done, it should hang off of XHR.
* Let me use the word *Lazy* until we get a consensus upon the term.
As stated at the proposal, we came up with certain use cases in Web Intents
postResult() callback. In this use case, there is no certain moment at which
the client can explicitly trigger XHR request. Rather, it has to wait huge
Blobs of data (e.g., an array of Media objects in the Pick Media Intent [1]) on
its intents callback.
Here is an example:
[Client]
navigator.startActivity(intent, mediaOK, mediaFail);
function mediaOK (mediaObjectArray) {
// iterate over the array of media objects to do something useful with them
console.log(mediaObjectArray.length + media objects) // In console,
250 media objects
for (var i = 0; i mediaObjectArray.length; i++) {
// read mediaObjectArray[i].content.blob triggers actual resource
transfer
}
}
At the point the mediaOK() callback is called, 250 *Lazy* Blobs from an image
gallery is ready.
[Service]
var mediaObjectArray = [];
// e.g., the service builds *mediaObjectArray* containing hundreds of png files
from an image gallery
{ // loop
var bb = new BlobBuilder()
, blob = bb.getBlobFromURL(http://specification.com/kitten00.png;,
GET, { Authorization: Basic DEADBEEF });
var content = {};
content.blob = blob;
mediaObject.content = content;
mediaObjectArray.push(mediaObject);
}
window.intent.postResult(mediaObjectArray);
Personally, I prefer option B (used in this email) as it is fairly simple to
developers while providing useful options.
[1] http://w3c-test.org/dap/gallery/
Regards,
Jungkee
Jungkee Song
Samsung Electronics
