Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
Whomever adds delete/continue back to the spec needs to inline into the spec an explanation of why it's ok per ES5. Most (all) of us grew up pre ES5 and *believe* that they're truly reserved keywords and that what you're doing is invalid. So without inlining the explanation into the spec, you're asking for people to think you're crazy. Personally, i think trying to mark something as locally unreserved is crazy, since you're fighting the web's collective knowledge. http://javascript.about.com/od/reference/g/rdelete.htm Definition: The delete statement deletes an object that was created using the new statement. Delete is a reserved word and cannot be used for anything other than deleting an object. Note that it seems clear that people here do not care about the web's collective knowledge, so I'm not asking you to stop.
HTML Device element status
I realize that the HTML Device element [1] is still in its infancy but should the scope of this spec be modified to integrate with other APIs as proposed here: http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0026.html ? The proposed device element seems like the most logical fit for such a non-form-based control - Any extensions to input type=file would invoke a file picker which AFAICS would not make for an ideal UX for non-file-specific information interaction. Rather than getting in to the UI/UX of the device element, the ability to pass parameters to any resulting device control would open up a ton of possibilities. I know first hand that we don't deal in roadmaps, but should we assign some priority to fleshing out such a fundamental element as device? Many thanks, Richard [1] http://dev.w3.org/html5/html-device/
HTML Device element status
I think I'm asking this question in the wrong place and so I'm re-posting to the more appropriate public-html-comments list. ** Please be sure to remove public-webapps@w3.org from any replies to avoid cross-posting ** - Richard On Tue, Jul 6, 2010 at 12:41 PM, Rich Tibbett rich.tibb...@gmail.comwrote: I realize that the HTML Device element [1] is still in its infancy but should the scope of this spec be modified to integrate with other APIs as proposed here: http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0026.html ? The proposed device element seems like the most logical fit for such a non-form-based control - Any extensions to input type=file would invoke a file picker which AFAICS would not make for an ideal UX for non-file-specific information interaction. Rather than getting in to the UI/UX of the device element, the ability to pass parameters to any resulting device control would open up a ton of possibilities. I know first hand that we don't deal in roadmaps, but should we assign some priority to fleshing out such a fundamental element as device? Many thanks, Richard [1] http://dev.w3.org/html5/html-device/
Re: HTML Device element status
On Tue, 06 Jul 2010 13:41:27 +0200, Rich Tibbett rich.tibb...@gmail.com wrote: I know first hand that we don't deal in roadmaps, but should we assign some priority to fleshing out such a fundamental element as device? device was proposed to the DAP WG, not the WebApps WG. Other than that detailed planning of new features does not really work well. They need to evolve iteratively and at this point I think we need some kind of experimental implementation to see whether the feature can work at all. That will also give us a better idea whether overloading device is a sensible idea. Overloading went pretty badly with object. There are some advantages with input, but overall the design is ugly. Maybe here it makes sense but we should do some prototyping to be sure. -- Anne van Kesteren http://annevankesteren.nl/
Re: CfC: Candidate Recommendation of XMLHttpRequest; deadline July 13
Anne has now integrated the CR's exit criteria and text about security considerations into the version proposed for CR: [[ http://dev.w3.org/2006/webapi/XMLHttpRequest/#crec Candidate Recommendation Exit Criteria To exit the Candidate Recommendation (CR) stage the following criteria must have been met: 1. There will be at least two interoperable implementations passing all test cases in the test suite for this specification. An implementation is to be available (i.e. for download), shipping (i.e. not private), and not experimental (i.e. intended for a wide audience). The working group will decide when the test suite is of sufficient quality to test interoperability. 2. A minimum of six months of the CR stage will have elapsed. This is to ensure that enough time is given for any remaining major errors to be caught. The CR period will be extended if implementations are slow to appear. 3. Text, which can be in a separate document, exists that explains the security considerations for this specification. This may be done in a generic manner as they are most likely applicable to various APIs. The working group will decide whether the text is of sufficient quality. An update to this draft will point to the test suite. ]] As such, the comment period for this Call for Consensus is extended to July 13. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. -Art Barstow On 6/15/10 1:03 PM, Arthur Barstow wrote: This is a Call for Consensus to publish a Candidate Recommendation of XMLHttpRequest: http://dev.w3.org/2006/webapi/XMLHttpRequest/ The comment period for the 19 November 2009 LCWD of XHR [LC] ended 16 December 2009 and the disposition of comments for this LCWD is: http://dev.w3.org/2006/webapi/XMLHttpRequest/disposition-of-comments-3 During this CfC review period, Anne and Thomas agreed to work on the Security Considerations issue and others are welcome to contribute. A test suite has not been agreed by the Working Group, and will not be required for the CR to be published. However, agreeing on a test suite will be part of the work we will do before this spec can move further than CR. The Editor's Draft does not yet include CR exit criteria. I would expect the criteria to be similar to our previous CRs i.e. require a thorough test suite and at least two implementations that pass all tests. (We can discuss the criteria separately.) This CfC satisfies: a) the group's requirement to record the group's decision to request advancement to CR; and b) General Requirements for Advancement on the Recommendation Track as defined in the Process Document: http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs 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 June 30. -Art Barstow [LC] http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/
Re: HTML Device element status
On Tue, Jul 6, 2010 at 5:18 AM, Anne van Kesteren ann...@opera.com wrote: There are some advantages with input, but overall the design is ugly. input type=file is buffered, which would seem to exclude the possibility of onchange=form.submit() in any of its forms' elements, but is otherwise parsimonious, while device is its unbuffered counterpart. Why is one method of transmission any more or less ugly than the other? Buffering can substantially reduce bandwidth. Is there any reason not to protect both them with the same privacy and security authorization dialogs, and render them mostly the same, except for audio/* and video/* input you might have record/pause/play/submit while device would have record/pause? For image/* the differences are less clear to me: perhaps input would have a viewfinder, (expandable on mobiles) shutter button, a filesystem browser button, and an (optional?) submit button, but an image/* device might only have a viewfinder and a shutter button. For the case of a camera, it would seem to me that the buffered approach is also superior, but the unbuffered device approach would allow audio and video teleconferencing. Also, someone said it would be a good idea to mute audio input and output from any hidden tab. I think this may be a reasonable user option (people who listen to podcasts might not like it), and wonder if microphone or other audio input should be muted from any window and tab without top-most focus and exposure. Does anyone have thoughts on that question?
Web Notifications: public-web-notification created
The public-web-notification Mail List was created for the Web Notifications spec and the ML's archive is available at: http://lists.w3.org/Archives/Public/public-web-notification/ The above includes a subscribe to this list link. Original Message Subject:[Work in Progress on Web Notification Working Group Date: Wed, 30 Jun 2010 21:07:38 +0200 From: Barstow Art (Nokia-CIC/Boston) art.bars...@nokia.com Reply-To: Barstow Art (Nokia-CIC/Boston) art.bars...@nokia.com To: public-webapps public-webapps@w3.org Earlier today the W3C posted a Draft charter for a new Web Notification Working Group: http://www.w3.org/2010/06/notification-charter The primary objective of this WG is to move the Web Notifications spec to Recommendation: http://dev.w3.org/2006/webapi/WebNotifications/publish/ If you have any comments about the Draft charter, please send them to: public-webapps@w3.org -Art Barstow
RE: [IndexedDB] Editors
Nikunj, Jonas, All, Chaals, the Team and I all support this proposal. Thanks to you both! -Art Barstow From: public-webapps-requ...@w3.org [public-webapps-requ...@w3.org] On Behalf Of ext Nikunj Mehta [nik...@o-micron.com] Sent: Tuesday, July 06, 2010 12:39 PM To: public-webapps Subject: [IndexedDB] Editors Hi folks, I would like to propose adding Jonas Sicking to the list of editors for the IndexedDB spec. Many of you have seen the tremendous amount of work Jonas has done to assist in finalizing the asynchronous API as well as providing implementation feedback. I hope the WG will support this change. Best, Nikunj
Re: [IndexedDB] Editors
+1 On Tue, Jul 6, 2010 at 4:11 PM, art.bars...@nokia.com wrote: Nikunj, Jonas, All, Chaals, the Team and I all support this proposal. Thanks to you both! -Art Barstow From: public-webapps-requ...@w3.org [public-webapps-requ...@w3.org] On Behalf Of ext Nikunj Mehta [nik...@o-micron.com] Sent: Tuesday, July 06, 2010 12:39 PM To: public-webapps Subject: [IndexedDB] Editors Hi folks, I would like to propose adding Jonas Sicking to the list of editors for the IndexedDB spec. Many of you have seen the tremendous amount of work Jonas has done to assist in finalizing the asynchronous API as well as providing implementation feedback. I hope the WG will support this change. Best, Nikunj
Re: [IndexedDB] Current editor's draft
On Tue, Jul 6, 2010 at 9:36 AM, Nikunj Mehta nik...@o-micron.com wrote:
Hi folks,
There are several unimplemented proposals on strengthening and
expanding IndexedDB. The reason I have not implemented them yet is
because I am not convinced they are necessary in toto. Here's my
attempt at explaining why. I apologize in advance for not responding
to individual proposals due to personal time constraints. I will
however respond in detail on individual bug reports, e.g., as I did
with 9975.
I used the current editor's draft asynchronous API to understand where
some of the remaining programming difficulties remain. Based on this
attempt, I find several areas to strengthen, the most prominent of
which is how we use transactions. Another is to add the concept of a
catalog as a special kind of object store.
Hi Nikunj,
Thanks for replying! I'm very interested in getting this stuff sorted
out pretty quickly as almost all other proposals in one way or another
are affected by how this stuff develops.
Here are the main areas I propose to address in the editor's spec:
1. It is time to separate the dynamic and static scope transaction
creation so that they are asynchronous and synchronous respectively.
I don't really understand what this means. What are dynamic and static
scope transaction creation? Can you elaborate?
2. Provide a catalog object that can be used to atomically add/remove
object stores and indexes as well as modify version.
It seems to me that a catalog object doesn't really provide any
functionality over the proposal in bug 10052? The advantage that I see
with the syntax proposal in bug 10052 is that it is simpler.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052
Can you elaborate on what the advantages are of catalog objects?
3. Cursors may produce a null key or a null value. I don't see how
this is valid signaling for non-preloaded cursors. I think we need to
add a new flag on the cursor to find out if the cursor is exhausted.
Our proposal was that IDBEvent.result would normally contain the
cursor object, but once the end is reached it returns null. To be
clear:
When a value is found:
event.result; // returns cursor object, never null
event.result.key; // returns key, may be null
event.result.value; // returns value, may be null
When end is reached:
event.result; // returns null
A couple of additional points:
1. I did not see any significant benefits of preloaded cursors in
terms of programming ease.
Yes, there seems to be agreement that preloaded cursors should be
removed. I've removed them from our proposal.
2. *_NO_DUPLICATE simplifies programming as well as aids in good
performance. I have shown one example that illustrates this.
I'll have to analyze the examples below. My gut instinct though is
that I agree with you that they are needed.
3. Since it seems continue is acceptable to implementers, I am also
suggesting we use delete instead of remove, for consistency sake.
Agreed.
--- IDL
[NoInterfaceObject]
interface IDBDatabase {
readonly attribute DOMString name;
readonly attribute DOMString description;
readonly attribute DOMStringList objectStores;
/*
Open an object store in the specified transaction. The transaction can be
dynamic scoped, or the requested object store must be in the static scope.
Returns IDBRequest whose success event of IDBTransactionEvent type contains
a result with IDBObjectStore and transaction is an IDBTransactionRequest.
*/
IDBRequest openObjectStore(in DOMString name, in IDBTransaction txn,
in optional unsigned short mode /* defaults to READ_WRITE */);
I don't understand the advantage of this proposal over mozillas
proposal. One of our main points was to make getting objectStore
objects a synchronous operation as to avoid having to nest multiple
levels of asynchronous calls. Compare
var req = db.openObjectStore(foo, trans);
req.onerror = errorHandler;
req.onsuccess = function(e) {
var fooStore = e.result;
var req = fooStore.get(12);
req.onerror = errorHandler;
req.onsuccess = resultHandler;
}
to
var fooStore = db.openObjectStore(foo, trans);
var req = fooStore.get(12);
req.onerror = errorHandler;
req.onsuccess = resultHandler;
I also don't understand the advantage of having the transaction as an
argument to openObjectStore rather than having openObjectStore live on
transaction. Compare
db.openObjectStore(foo, trans);
to
trans.openObjectStore(foo);
I also don't understand the meaning of specifying a mode when a
objectStore is opened, rather than specifying the mode when the
transaction is created. Unless we're planning on making all
transactions dynamic (I hope not), locks have to be grabbed when the
transaction is created, right? If a transaction is holding a READ_ONLY
lock for a given objectStore, then attempting to open that objectStore
as READ_WRITE should obviously fail. Consecutively, if a transaction
is holding a READ_WRITE lock for a given
Re: [IndexedDB] Current editor's draft
On Wed, Jul 7, 2010 at 5:57 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jul 6, 2010 at 9:36 AM, Nikunj Mehta nik...@o-micron.com wrote:
Hi folks,
There are several unimplemented proposals on strengthening and
expanding IndexedDB. The reason I have not implemented them yet is
because I am not convinced they are necessary in toto. Here's my
attempt at explaining why. I apologize in advance for not responding
to individual proposals due to personal time constraints. I will
however respond in detail on individual bug reports, e.g., as I did
with 9975.
I used the current editor's draft asynchronous API to understand where
some of the remaining programming difficulties remain. Based on this
attempt, I find several areas to strengthen, the most prominent of
which is how we use transactions. Another is to add the concept of a
catalog as a special kind of object store.
Hi Nikunj,
Thanks for replying! I'm very interested in getting this stuff sorted
out pretty quickly as almost all other proposals in one way or another
are affected by how this stuff develops.
Here are the main areas I propose to address in the editor's spec:
1. It is time to separate the dynamic and static scope transaction
creation so that they are asynchronous and synchronous respectively.
I don't really understand what this means. What are dynamic and static
scope transaction creation? Can you elaborate?
This is the difference in the API in my email between openTransaction and
transaction. Dynamic and static scope have been defined in the spec for a
long time.
2. Provide a catalog object that can be used to atomically add/remove
object stores and indexes as well as modify version.
It seems to me that a catalog object doesn't really provide any
functionality over the proposal in bug 10052? The advantage that I see
with the syntax proposal in bug 10052 is that it is simpler.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052
Can you elaborate on what the advantages are of catalog objects?
To begin with, 10052 shuts down the users of the database completely when
only one is changing its structure, i.e., adding or removing an object
store. How can we make it less draconian? Secondly, I don't see how that
approach can produce atomic changes to the database. Thirdly, we shouldn't
need to change version in order to perform database changes. Finally, I am
not sure why you consider the syntax proposal simpler. Note that I am not
averse to the version change event notification.
3. Cursors may produce a null key or a null value. I don't see how
this is valid signaling for non-preloaded cursors. I think we need to
add a new flag on the cursor to find out if the cursor is exhausted.
Our proposal was that IDBEvent.result would normally contain the
cursor object, but once the end is reached it returns null. To be
clear:
When a value is found:
event.result; // returns cursor object, never null
event.result.key; // returns key, may be null
event.result.value; // returns value, may be null
When end is reached:
event.result; // returns null
Got it. I will try out this approach.
A couple of additional points:
1. I did not see any significant benefits of preloaded cursors in
terms of programming ease.
Yes, there seems to be agreement that preloaded cursors should be
removed. I've removed them from our proposal.
2. *_NO_DUPLICATE simplifies programming as well as aids in good
performance. I have shown one example that illustrates this.
I'll have to analyze the examples below. My gut instinct though is
that I agree with you that they are needed.
3. Since it seems continue is acceptable to implementers, I am also
suggesting we use delete instead of remove, for consistency sake.
Agreed.
--- IDL
[NoInterfaceObject]
interface IDBDatabase {
readonly attribute DOMString name;
readonly attribute DOMString description;
readonly attribute DOMStringList objectStores;
/*
Open an object store in the specified transaction. The transaction can
be
dynamic scoped, or the requested object store must be in the static
scope.
Returns IDBRequest whose success event of IDBTransactionEvent type
contains
a result with IDBObjectStore and transaction is an
IDBTransactionRequest.
*/
IDBRequest openObjectStore(in DOMString name, in IDBTransaction txn,
in optional unsigned short mode /* defaults to READ_WRITE */);
I don't understand the advantage of this proposal over mozillas
proposal.
The above proposal allows opening multiple object stores in the same
transaction in dynamic scope, even without having explicitly identified each
one of them at the time of creating the transaction. Secondly, where static
scope is desired, in order to run to completion without being aborted due to
unavailable objects, this proposal ensures that locks are obtained at the
time of creating the transaction.
My
Re: [IndexedDB] Editors
Sounds great! On Wed, Jul 7, 2010 at 12:39 AM, Nikunj Mehta nik...@o-micron.com wrote: Hi folks, I would like to propose adding Jonas Sicking to the list of editors for the IndexedDB spec. Many of you have seen the tremendous amount of work Jonas has done to assist in finalizing the asynchronous API as well as providing implementation feedback. I hope the WG will support this change. Best, Nikunj
