Re: [XHR2] ArrayBuffer support added
On Mon, 31 Jan 2011 10:17:23 +0100, Anne van Kesteren ann...@opera.com wrote: I somehow missed that a request to add back ArrayBuffer support was offlist. Since quite a few specifications are using it now and TC 39 has shown no progress on developing an alternative I was convinced to add it back in. The responseType value is arraybuffer. This adds a dependency to the Typed Array specification developed at Khronos. http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ I summarized a bit unfairly towards TC 39. The expectation is that TC 39 does not move as fast as Khronos and that therefore ArrayBuffer will likely stick around. If it turns out it can be replaced XMLHttpRequest will just follow along of course. -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] ArrayBuffer support added
On Mon, 31 Jan 2011 18:27:51 +0100, Charles Pritchard ch...@visc.us wrote: While on that topic, it'd be nice to see a fixed-size ArrayBuffer, for working with streams and large-files. Currently: blob requires the entire file be downloaded before use, classically, the stream could be ready while downloading, and the final response just 'tossed' (when the stream is complete). Even a hard-coded array buffer size would be helpful (though it'd be nice to have that as a settable value): Something along these lines would allow processing of binary data without requiring the entire stream to be loaded into memory / downloaded. xhr.responseType='stream' xhr.buffer = new ArrayBuffer(...len...); I hope we can actually just do this by exposing blob earlier than DONE in due course. With the Blob object on disk growing over time. If you really just want to stream data I think we should use EventSource for that. -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] Questions regarding to Test Suite for the XML Digital Signatures For Widgets Specification
Hi Marcos, On Jan/31/2011 2:18 PM, ext Marcos Caceres wrote: On 1/31/11 7:52 PM, Arthur Barstow wrote: Andrey - on January 26, Marcos proposed changing the c14n algorithm in [1] and [2] and notified the group in [3] that he updated the Editor's Draft [ED] to reflect his proposal. He included rationale in [1]. Marcos - in what way(s) does your proposal break the signer and validator conformance classes as defined in the June 2010 CR [CR]? It would remove all references and dependencies on XML Canonicalization 1.1 in favor of XML Canonicalization 1.0. Explicit tranform to Canonicalization 1.1 would no longer be needed (XML Dig Sig just defaults to 1.0). Everything else stays the same. If an old widget is signed according to [CR] i.e. uses the ExC14N algorithm and a new validator is implemented according to the proposed changes (now reflected in [ED), then what happens when this new validator process this old widget? Based on what you and I just discussed in IRC, I believe the validation will fail. Correct? It would be useful if we had at least a general idea regarding the number of widgets in the wild that are signed using the ExC14N algorithm. If anyone has relevant data, please send it to this mail list. -Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0247.html [2] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0250.html [3] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0254.html [ED] http://dev.w3.org/2006/waf/widgets-digsig/ [CR] http://www.w3.org/TR/2010/CR-widgets-digsig-20100624/#conformance
Re: [XHR2] ArrayBuffer support added
(I didn't send the previous mail to the list, so sending again) I hope we can actually just do this by exposing blob earlier than DONE in due course. With the Blob object on disk growing over time. If you really just want to stream data I think we should use EventSource for that. IMHO, EventSource is too cumbersome to handle binaries as you have to special-case both CR and LF, and CRLF sequence. A.TAKAYAMA
Re: [XHR2] ArrayBuffer support added
On Tue, 01 Feb 2011 14:58:02 +0100, ATSUSHI TAKAYAMA taka.atsu...@googlemail.com wrote: (I didn't send the previous mail to the list, so sending again) I hope we can actually just do this by exposing blob earlier than DONE in due course. With the Blob object on disk growing over time. If you really just want to stream data I think we should use EventSource for that. IMHO, EventSource is too cumbersome to handle binaries as you have to special-case both CR and LF, and CRLF sequence. That it does not deal with raw octet-data now does not mean it will not in the future. -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] Questions regarding to Test Suite for the XML Digital Signatures For Widgets Specification
On 2/1/11 1:41 PM, Arthur Barstow wrote: Hi Marcos, On Jan/31/2011 2:18 PM, ext Marcos Caceres wrote: On 1/31/11 7:52 PM, Arthur Barstow wrote: Andrey - on January 26, Marcos proposed changing the c14n algorithm in [1] and [2] and notified the group in [3] that he updated the Editor's Draft [ED] to reflect his proposal. He included rationale in [1]. Marcos - in what way(s) does your proposal break the signer and validator conformance classes as defined in the June 2010 CR [CR]? It would remove all references and dependencies on XML Canonicalization 1.1 in favor of XML Canonicalization 1.0. Explicit tranform to Canonicalization 1.1 would no longer be needed (XML Dig Sig just defaults to 1.0). Everything else stays the same. If an old widget is signed according to [CR] i.e. uses the ExC14N algorithm and a new validator is implemented according to the proposed changes (now reflected in [ED), then what happens when this new validator process this old widget? Based on what you and I just discussed in IRC, I believe the validation will fail. Correct? Correct. It would be useful if we had at least a general idea regarding the number of widgets in the wild that are signed using the ExC14N algorithm. If anyone has relevant data, please send it to this mail list. Absolutely! -- Marcos Caceres Opera Software
[Bug 11947] New: [IndexedDB] Updating object stores with auto increment
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11947
Summary: [IndexedDB] Updating object stores with auto increment
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: h...@chromium.org
QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org
In 5.1 Object Store Storage Operation, step 1 it says: If store uses
a key generator and key is undefined, set key to the next generated
key. If store also uses in-line keys, then set the property in value
pointed to by store's key path to the new value for key.
But in the object store example in 3.3.3, there is the following:
A second put operation will overwrite the record stored by the first
put operation.
var abraham = {id: 1, name: 'Abraham', number: '2107'};
store.put(abraham);
However, the way I read the specification, the key generator will
generate the key 2, and then set the id property in the value to 2.
So this operation does not at all overwrite the first record, and the
next statement in the example: Now when the object store is read with
the same key, the result is different compared to the object read
earlier. is false.
To me, it would make sense that:
1. If a user provides an explicit key to an operation on an object
store that has a key generator, then the explicit key takes
precedence, and the key generator doesn't do anything.
2. If a user provides an in-line key, then that key takes precedence,
and the key generator doesn't do anything.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[FileAPI] FileReader.abort() fires both error and abort
Hi http://dev.w3.org/2006/webapi/FileAPI/#abort Why does it fire both error and abort? Shouldn't it just fire abort? -- Simon Pieters Opera Software
IndexedDB: updates through cursors on indexes that change the key
For cursors on object stores, we disallow updates that change the key:
one cannot provide an explicit key, and for object stores with a key
path, the spec says that If the effective object store of this cursor
uses in-line keys and evaluating the key path of the value parameter
results in a different value than the cursor's effective key, this
method throws DATA_ERR.
I suppose the reason is that an implementation may have trouble
handling such updates, i.e. changing the keys that the cursor iterates
over during the iteration is a bad idea.
A similar situation can occur with cursors over indexes:
Say that there is an object store with objects like {fname: 'John',
lname: 'Doe', phone: 1234}, and an index with 'fname' as key path.
When iterating over the index with a cursor, should it be allowed to
update the objects so that the key in the index, in this case the
'fname', of an object is changed? The situation seems analogous to the
one above, but as far as I can see, the spec does not mention this.
Should it be allowed?
I would be interested to hear your thoughts on this.
Thanks,
Hans
[widgets] New version of PC Ready for pub
Hi, I have updated the Wigets PC spec for publication as a LC. This new draft specifies the defaultlocale attribute and makes some clarifications identified during the previous LC: [[ Changes Since Last Publication This version introduces the defaultlocale attribute. For widgets that make use of multiple languages, this attribute allows an author to specify which of the languages should be used in case the user agent does not support any of the languages specified by the widget. The following example shows the expected usage of the new defaultlocale attribute. In case neither English or Portuguese is supported by the runtime, the English version will be chosen by default: widget xmlns = http://www.w3.org/ns/widgets; defaultlocale = en-us name short=Weather xml:lang=en-us The Ultimate Weather Widget /name name short=Boletim xml:lang=pt Boletim Metereológico /name /widget As there was confusion with regards to the email attribute and the param elements name and value attributes being defined as keyword attributes, these have now been reclassified as a string attributes. ]] Kind regards, Marcos
[Bug 11948] New: index.openCursor's cursor should have a way to access the index's value (in addition to the index's key and objectStore's value)
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11948 Summary: index.openCursor's cursor should have a way to access the index's value (in addition to the index's key and objectStore's value) Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org As discussed in the mailing list thread from bug 11257, we should add some way for index.openCursor cursors to access the primary key for the objectStore. .indexValue, .objectStoreKey, or .primaryKey might be good names to use for it. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: IndexedDB: updates through cursors on indexes that change the key
On Tue, Feb 1, 2011 at 10:07 AM, Hans Wennborg h...@chromium.org wrote:
For cursors on object stores, we disallow updates that change the key:
one cannot provide an explicit key, and for object stores with a key
path, the spec says that If the effective object store of this cursor
uses in-line keys and evaluating the key path of the value parameter
results in a different value than the cursor's effective key, this
method throws DATA_ERR.
I suppose the reason is that an implementation may have trouble
handling such updates, i.e. changing the keys that the cursor iterates
over during the iteration is a bad idea.
A similar situation can occur with cursors over indexes:
Say that there is an object store with objects like {fname: 'John',
lname: 'Doe', phone: 1234}, and an index with 'fname' as key path.
When iterating over the index with a cursor, should it be allowed to
update the objects so that the key in the index, in this case the
'fname', of an object is changed? The situation seems analogous to the
one above, but as far as I can see, the spec does not mention this.
Should it be allowed?
I would be interested to hear your thoughts on this.
I think we should remove the original limitation instead. While a cursor is
happening, anyone can call .remove() and .put() which is essentially the
same as doing an .update() which changes a key. So implementations will
already need to handle this case one way or another. What's there seems
like a fairly artificial limitation.
J
Re: IndexedDB: updates through cursors on indexes that change the key
On Tue, Feb 1, 2011 at 11:44 AM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Feb 1, 2011 at 10:07 AM, Hans Wennborg h...@chromium.org wrote:
For cursors on object stores, we disallow updates that change the key:
one cannot provide an explicit key, and for object stores with a key
path, the spec says that If the effective object store of this cursor
uses in-line keys and evaluating the key path of the value parameter
results in a different value than the cursor's effective key, this
method throws DATA_ERR.
I suppose the reason is that an implementation may have trouble
handling such updates, i.e. changing the keys that the cursor iterates
over during the iteration is a bad idea.
A similar situation can occur with cursors over indexes:
Say that there is an object store with objects like {fname: 'John',
lname: 'Doe', phone: 1234}, and an index with 'fname' as key path.
When iterating over the index with a cursor, should it be allowed to
update the objects so that the key in the index, in this case the
'fname', of an object is changed? The situation seems analogous to the
one above, but as far as I can see, the spec does not mention this.
Should it be allowed?
I would be interested to hear your thoughts on this.
I think we should remove the original limitation instead. While a cursor is
happening, anyone can call .remove() and .put() which is essentially the
same as doing an .update() which changes a key. So implementations will
already need to handle this case one way or another. What's there seems
like a fairly artificial limitation.
The tricky part if you allow modifying the primary key is defining the
exact semantics around that, especially going forward if we add things
like events or audit logs or anything like that (something like that
is likely going to be needed for syncing). As things stand now, a call
to cursor.update() is semantically equivalent to a call to
objectStore.put(). If we allow modifying the key that is no longer the
case.
So we would then need to define things like does cursor.update() equal
objectStore.remove() and then objectStore.add() always? Or just when
the key is actually changed? And what happens if the new key already
exists in the database? Does that undo both the remove() and the
add(), fail, or do you risk losing the entry? Or does cursor.update()
equal objectStore.remove() and then objectStore.put() such that if an
entry with the key already exists, it is overwritten?
So I don't think the concern here is about confusing the cursor
object. Like Jeremy points out, cursors have to deal with the iterated
data changing anyway. I think the main reason for the current
restriction is to keep the set of operations that you can perform on
the data simpler.
Of course, if there is reason to allow modifying the primary key, then
we'll just have to deal with the more complex set of allowed
operations. But then it would probably also make sense to allow
modifying the primary key of an existing entry directly on the
objectStore, without having to go through a cursor.
/ Jonas
Re: IndexedDB: updates through cursors on indexes that change the key
Has anyone heard of or proposed any kind of use case where it would be valuable to change the primary key of an object in the object store (outside, or inside, a cursor)? -Ben Turner
Re: IndexedDB: updates through cursors on indexes that change the key
On Tue, Feb 1, 2011 at 2:56 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Feb 1, 2011 at 11:44 AM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Feb 1, 2011 at 10:07 AM, Hans Wennborg h...@chromium.org
wrote:
For cursors on object stores, we disallow updates that change the key:
one cannot provide an explicit key, and for object stores with a key
path, the spec says that If the effective object store of this cursor
uses in-line keys and evaluating the key path of the value parameter
results in a different value than the cursor's effective key, this
method throws DATA_ERR.
I suppose the reason is that an implementation may have trouble
handling such updates, i.e. changing the keys that the cursor iterates
over during the iteration is a bad idea.
A similar situation can occur with cursors over indexes:
Say that there is an object store with objects like {fname: 'John',
lname: 'Doe', phone: 1234}, and an index with 'fname' as key path.
When iterating over the index with a cursor, should it be allowed to
update the objects so that the key in the index, in this case the
'fname', of an object is changed? The situation seems analogous to the
one above, but as far as I can see, the spec does not mention this.
Should it be allowed?
I would be interested to hear your thoughts on this.
I think we should remove the original limitation instead. While a cursor
is
happening, anyone can call .remove() and .put() which is essentially the
same as doing an .update() which changes a key. So implementations will
already need to handle this case one way or another. What's there seems
like a fairly artificial limitation.
The tricky part if you allow modifying the primary key is defining the
exact semantics around that, especially going forward if we add things
like events or audit logs or anything like that (something like that
is likely going to be needed for syncing). As things stand now, a call
to cursor.update() is semantically equivalent to a call to
objectStore.put(). If we allow modifying the key that is no longer the
case.
So we would then need to define things like does cursor.update() equal
objectStore.remove() and then objectStore.add() always? Or just when
the key is actually changed? And what happens if the new key already
exists in the database? Does that undo both the remove() and the
add(), fail, or do you risk losing the entry? Or does cursor.update()
equal objectStore.remove() and then objectStore.put() such that if an
entry with the key already exists, it is overwritten?
So I don't think the concern here is about confusing the cursor
object. Like Jeremy points out, cursors have to deal with the iterated
data changing anyway. I think the main reason for the current
restriction is to keep the set of operations that you can perform on
the data simpler.
Of course, if there is reason to allow modifying the primary key, then
we'll just have to deal with the more complex set of allowed
operations. But then it would probably also make sense to allow
modifying the primary key of an existing entry directly on the
objectStore, without having to go through a cursor.
Good points (against having it remove the original key if it changes).
After some more thought: The original idea behind cursor.delete() and
cursor.update() was that they would basically just be aliases for
objectStore.delete() and objectStore.put(). Maybe calling .update() with a
changed primary key should simply have the same behavior as .put(). Thus
the value corresponding to the original key would be left unmodified and the
new key would then correspond to the new value.
I can't think of any examples where the current behavior would get in
someone's way though. So I guess maybe we should just leave it as is. But
I still hate the idea of it being subtly different from being a straight up
alias to put.
J
Re: IndexedDB: updates through cursors on indexes that change the key
Surely the cursor should be atomic, representing the instant in time the query executed. Any updates or deletes etc would not be visible to the cursor, only to later queries. Then you can allow any modifications including to keys and indexes. Cheers, Keean On 2 Feb 2011 00:05, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 1, 2011 at 2:56 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 1, 2011 at 11:44 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 1, 2... Good points (against having it remove the original key if it changes). After some more thought: The original idea behind cursor.delete() and cursor.update() was that they would basically just be aliases for objectStore.delete() and objectStore.put(). Maybe calling .update() with a changed primary key should simply have the same behavior as .put(). Thus the value corresponding to the original key would be left unmodified and the new key would then correspond to the new value. I can't think of any examples where the current behavior would get in someone's way though. So I guess maybe we should just leave it as is. But I still hate the idea of it being subtly different from being a straight up alias to put. J
Re: IndexedDB: updates through cursors on indexes that change the key
No, that idea was rejected a while ago. IndexedDB cursors are live, so any change made during the cursor are visible to the cursor as well as later queries. -Ben Turner On Tue, Feb 1, 2011 at 4:35 PM, Keean Schupke ke...@fry-it.com wrote: Surely the cursor should be atomic, representing the instant in time the query executed. Any updates or deletes etc would not be visible to the cursor, only to later queries. Then you can allow any modifications including to keys and indexes. Cheers, Keean On 2 Feb 2011 00:05, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 1, 2011 at 2:56 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 1, 2011 at 11:44 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Feb 1, 2... Good points (against having it remove the original key if it changes). After some more thought: The original idea behind cursor.delete() and cursor.update() was that they would basically just be aliases for objectStore.delete() and objectStore.put(). Maybe calling .update() with a changed primary key should simply have the same behavior as .put(). Thus the value corresponding to the original key would be left unmodified and the new key would then correspond to the new value. I can't think of any examples where the current behavior would get in someone's way though. So I guess maybe we should just leave it as is. But I still hate the idea of it being subtly different from being a straight up alias to put. J
Re: IndexedDB: updates through cursors on indexes that change the key
That seems to be different from accepted practice in databases. I On 2 Feb 2011 00:39, ben turner bent.mozi...@gmail.com wrote: No, that idea was rejected a while ago. IndexedDB cursors are live, so any change made during the cursor are visible to the cursor as well as later queries. -Ben Turner On Tue, Feb 1, 2011 at 4:35 PM, Keean Schupke ke...@fry-it.com wrote: Surely the cursor should ...
Re: IndexedDB: updates through cursors on indexes that change the key
Sorry, sent that before I was finished. Seems prone to problems in environments with multiple parallel accesses to the same database. I guess I would need to do an atomic copy of the elements to a separate object store to iterate throught? Is there a way of atomically copying a set of objects? Cheers, Keean. On 2 Feb 2011 00:41, Keean Schupke ke...@fry-it.com wrote: That seems to be different from accepted practice in databases. I On 2 Feb 2011 00:39, ben turner bent.mozi...@gmail.com wrote: No, that idea was rejecte... On Tue, Feb 1, 2011 at 4:35 PM, Keean Schupke ke...@fry-it.com wrote: Surely the cursor should ...
Re: IndexedDB: updates through cursors on indexes that change the key
On Tue, Feb 1, 2011 at 4:48 PM, Keean Schupke ke...@fry-it.com wrote: Sorry, sent that before I was finished. Seems prone to problems in environments with multiple parallel accesses to the same database. As long as you're inside a transaction, no other environments (be they separate tabs running in a separate process, workers running in a separate thread, or separate components running in the same page) will be able to mutate the data under you. / Jonas
Re: IndexedDB: updates through cursors on indexes that change the key
So whats the benefit of allowing a cursor to modify the data under it? Cheers, Keean. On 2 February 2011 01:17, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 1, 2011 at 4:48 PM, Keean Schupke ke...@fry-it.com wrote: Sorry, sent that before I was finished. Seems prone to problems in environments with multiple parallel accesses to the same database. As long as you're inside a transaction, no other environments (be they separate tabs running in a separate process, workers running in a separate thread, or separate components running in the same page) will be able to mutate the data under you. / Jonas
Re: IndexedDB: updates through cursors on indexes that change the key
Please look at the mail archives. IIRC, it seemed confusing that you could be looking at old data. Iterating on live data seems more consistent with run to completion semantics. J On Tue, Feb 1, 2011 at 5:26 PM, Keean Schupke ke...@fry-it.com wrote: So whats the benefit of allowing a cursor to modify the data under it? Cheers, Keean. On 2 February 2011 01:17, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 1, 2011 at 4:48 PM, Keean Schupke ke...@fry-it.com wrote: Sorry, sent that before I was finished. Seems prone to problems in environments with multiple parallel accesses to the same database. As long as you're inside a transaction, no other environments (be they separate tabs running in a separate process, workers running in a separate thread, or separate components running in the same page) will be able to mutate the data under you. / Jonas
Re: IndexedDB: updates through cursors on indexes that change the key
I see. I suppose for the relational stuff that I am doing I will have to copy all the data in the cursor, otherwise it will mess up updates and inserts with nested selects. Cheers, Keean. On 2 Feb 2011 01:32, Jeremy Orlow jor...@chromium.org wrote: Please look at the mail archives. IIRC, it seemed confusing that you could be looking at old data. Iterating on live data seems more consistent with run to completion semantics. J On Tue, Feb 1, 2011 at 5:26 PM, Keean Schupke ke...@fry-it.com wrote: So whats the benefit o...
Re: [widgets] Questions regarding to Test Suite for the XML Digital Signatures For Widgets Specification
Thank you, I have one more question: Test 19dsa.wgt. The deal is when I look on the certificate that is used for this test I see that it contains information about DSA Public Key, but the Signature Algorithm for this certificate is pointed as SHA1withRSA. Is it correct? I am not familiar with DSA algorithm.But in other places where I look into certificate with DSA Public Key, I saw that certificate is signed with DSA and the SHA-1 hash algorithm (for instance here: http://www.ietf.org/rfc/rfc2459.txt) Also as I understand the signature value after DSA algorithm using shall contain two big integer, written in the (ASN.1) form, but in this test I see only some byte array without any ASN.1 tags. May be the signature value is packed somehow? Haw can I unpack it? Regards, Andrey On 1/31/2011 9:52 PM, Arthur Barstow wrote: Andrey - on January 26, Marcos proposed changing the c14n algorithm in [1] and [2] and notified the group in [3] that he updated the Editor's Draft [ED] to reflect his proposal. He included rationale in [1].
