Re: CfC: to publish First Public Working Draft of Uniform Messaging Policy spec; deadline January 19
On Jan 13, 2010, at 00:29 , Arthur Barstow wrote: This is a Call for Consensus (CfC) to publish the First Public Working Draft (FPWD) of the Uniform Messaging Policy (UMP) spec, latest Editor's Draft at: http://dev.w3.org/2006/waf/UMP/ This CfC satisfies the group's requirement to record the group's decision to request advancement. +1 for publication. The only thing I don't like is the name, it's heavily politically charged in French. -- Robin Berjon - http://berjon.com/
Re: File API: Blob and underlying file changes.
On Tue, Jan 12, 2010 at 5:28 PM, Chris Prince cpri...@google.com wrote: For the record, I'd like to make the read atomic, such that you can never get half a file before a change, and half after. But it likely depends on what OSs can enforce here. I think *enforcing* atomicity is difficult across all OSes. But implementations can get nearly the same effect by checking the file's last modification time at the start + end of the API call. If it has changed, the read operation can throw an exception. I'm talking about during the actual read. I.e. not related to the lifetime of the File object, just related to the time between the first 'progress' event, and the 'loadend' event. If the file changes during this time there is no way to fake atomicity since the partial file has already been returned. / Jonas
[widgets] No Voice Conf on 14 January; next call is 21 January
The next widgets voice conference will be January 21 (there will not be a call on the 14th). Among the higher priority work items: * WARP spec - respond to LC comments and update the LC comment tracking doc Marcos; Dec 21: http://www.w3.org/mid/ b21a10670912210706w1d04c972j1c40236c0a864...@mail.gmail.com Dom; Dec 10: http://www.w3.org/mid/1260460310.3355.2561.ca...@localhost LC tracking doc: http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets- access-20091208/ * Scheme spec - continue to discuss LC comments http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets- uri-20091008/doc/ * View Modes Media Feature - move toward LC http://dev.w3.org/2006/waf/widgets-vmmf/ * View Modes Interfaces - continue to prepare for FPWD http://dev.w3.org/2006/waf/widgets-vm/vm-interfaces.src.html Open Widget Actions: please update accordingly: http://www.w3.org/2008/webapps/track/products/8 -Art Barstow
Re: CfC: to publish First Public Working Draft of Uniform Messaging Policy spec; deadline January 19
On Wed, Jan 13, 2010 at 12:29 AM, Arthur Barstow art.bars...@nokia.com wrote: This is a Call for Consensus (CfC) to publish the First Public Working Draft (FPWD) of the Uniform Messaging Policy (UMP) spec, latest Editor's Draft at: http://dev.w3.org/2006/waf/UMP/ This CfC satisfies the group's requirement to record the group's decision to request advancement. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does not necessarily mean there is consensus on the spec's contents. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is January 19. +1 for publication. -- Marcos Caceres http://datadriven.com.au
Re: MPEG-U
Hi Robin, Le 12/01/2010 18:13, Robin Berjon a écrit : Hi Cyril, On Jan 12, 2010, at 17:34 , Cyril Concolato wrote: Le 11/01/2010 15:41, Robin Berjon a écrit : Ah, do you have a pointer? I searched for MPEG-U in all the public and member lists yet only this thread shows up. The liaison was sent by the ISO/IEC/JTC1/SC29 secretariat, and since MPEG did not receive any feedback, I checked and was informed that it was mistakenly sent to Tim Berners Lee ! I informed Doug and Mike of that fact, I thought that it would be discussed in the WG. Anyway it doesn't matter anymore since I think the liaison is outdated. Heh! I know it's hard to get any ISO secretariat to do the right thing with liaisons, but the best for liaisons is to send them directly to this list, preferably through a common member (like the equally delightfully named ISO/IEC JTC1/SC34/WG4 recently did). Yes, you're right, the problem is that liaisons usually are not considered as public documents so the secretariat or MPEG members are not allowed to make them public. If avoidable I'd rather not join yet another mailing list just for a few questions, after which I'd have to unsubscribe again. Since you're closely involved with this work, would you mind answering the questions I outlined in my original post? I'm sorry but the only questions in your email were what's happening aroung MPEG-U ? and Can you enlighten us ?. I thought the web page I set up was providing enough information (background, roadmap, spec). Can you be more precise as to what you want to know ? I'm sorry, I realise that my original message isn't entirely clear in terms of what enlightening us covers :). The web page you sent is indeed helpful in describing MPEG-U, but I had other questions. Here is the part that the enlightenment intended to cover: One reason I'm asking is because some of the work items in that document are interesting in a generic manner, and therefore are things that could make their way into WebApp's charter when it comes up for rechartering (which is soon). I don't think that all that's listed there would be of interest to WebApps (e.g. I'd be surprised if the WG cared about integration with BIFS or ISOFF packaging, assuming members even have heard of them), but some topics (inter-widget communication, context management, aggregation) certainly are. Given MPEG's patent policy and inexperience with web technology one can take a fairly good bet that if MPEG-U defines solutions in this space WebApps won't adopt them, thereby leading to fragmentation: something that the document above states it wishes to avoid. So to make the question more explicit: given the stated goal of avoiding fragmentation (with which I strongly agree) in conjunction with the risk inherent in doing work that won't be adopted or that will take place in parallel, are you aware of any plans in the MPEG-U community to avoid fragmentation on topics that WebApps is likely to take up? That's a good question. My personal understanding was that the initial plan was to have MPEG work on specific topics (and until now the items dealt with by MPEG were not in any W3C charter), to liaise with other standardization bodies working in the area to make sure they are aware of the work done in MPEG and then to coordinate with them to harmonize the solution if necessary. So it would be good if the WG could inform MPEG about the evolution of its charter and possibly have a look at the MPEG spec, and comment on it. Anyway, MPEG is meeting next week, I'll raise your questions and try to have MPEG make a formal answer. Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: MPEG-U
Hi, Cyril- Cyril Concolato wrote (on 1/13/10 10:37 AM): Yes, you're right, the problem is that liaisons usually are not considered as public documents so the secretariat or MPEG members are not allowed to make them public. ... Anyway, MPEG is meeting next week, I'll raise your questions and try to have MPEG make a formal answer. Could you please make sure that the secretariat sends the email to team-liais...@w3.org, CCing Steven, Mike, and me, as the Team Contacts for the WebApps WG, and Philippe Le Hegaret as Interaction Domain Lead? It's not appropriate to email Tim Berners-Lee for liaisons at this level, though if they insist, I suppose they can include him. We need to make sure that these liaisons are dealt with in a timely manner. I would greatly appreciate if you could have the secretariat send an immediate acknowledgment email to the above email addresses, just to make sure that the process is understood and accepted, before sending the liaison itself. Could you please request that right away? I know you are doing what you can to make sure the communication channels are clear, so I appreciate your help. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: File API: Blob and underlying file changes.
Atomic read is obviously a nice thing - it would be hard to program against API that behaves as unpredictably as a single read operation that reads half of old content and half of new content. At the same note, it would be likely very hard to program against Blob objects if they could change underneath unpredictably. Imagine that we need to build an uploader that cuts a big file in multiple pieces and sends those pieces to the servers so they will be stitched together later. If during this operation the underlying file changes and this changes all the pieces that Blobs refer to (due to clamping and just silent change of content), all the slicing/stitching assumptions are invalid and it's hard to even notice since blobs are simply 'clamped' silently. Some degree of mess is possible then. Another use case could be a JPEG image processor that uses slice() to cut the headers from the image file and then uses info from the headers to cut further JFIF fields from the file (reading EXIF and populating local database of images for example). Changing the file in the middle of that is bad. It seems the typical use cases that will need Blob.slice() functionality form 'units of work' where Blob.slice() is used with likely assumption that underlying data is stable and does not change silently. Such a 'unit of work' should fail as a whole if underlying file changes. One way to achieve that is to reliably fail operations with 'derived' Blobs and even perhaps have a 'isValid' property on it. 'Derived' Blobs are those obtained via slice(), as opposite to 'original' Blobs that are also File. One disadvantage of this approach is that it implies that the same Blob has 2 possible behaviors - when it is obtained via Blob.slice() (or other methods) vs is a File. It all could be a bit cleaner if File did not derive from Blob, but instead had getAsBlob() method - then it would be possible to say that Blobs are always immutable but may become 'invalid' over time if underlying data changes. The FileReader can then be just a BlobReader and have cleaner semantics. If that was the case, then xhr.send(file) would capture the state of file at the moment of sending, while xhr.send(blob) would fail with exception if the blob is 'invalid' at the moment of send() operation. This would keep compatibility with current behavior and avoid duplicity of Blob behavior. Quite a change to the spec though... Dmitry On Wed, Jan 13, 2010 at 2:38 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jan 12, 2010 at 5:28 PM, Chris Prince cpri...@google.com wrote: For the record, I'd like to make the read atomic, such that you can never get half a file before a change, and half after. But it likely depends on what OSs can enforce here. I think *enforcing* atomicity is difficult across all OSes. But implementations can get nearly the same effect by checking the file's last modification time at the start + end of the API call. If it has changed, the read operation can throw an exception. I'm talking about during the actual read. I.e. not related to the lifetime of the File object, just related to the time between the first 'progress' event, and the 'loadend' event. If the file changes during this time there is no way to fake atomicity since the partial file has already been returned. / Jonas
