Re: [XHR2] ArrayBuffer support added

[Anne van Kesteren]

On Fri, 04 Mar 2011 01:45:08 +0100, Charles Pritchard   
wrote:
Following up on this older thread, Mozilla has added ArrayBuffer to  
their XHR object, though the documentation

is a little bare.

xhr.mozResponseArrayBuffer


That feature is already in the draft via responseType/response.


--
Anne van Kesteren
http://annevankesteren.nl/

Some additions to Web Workers

[João Eiras]

Hi.

It seems Mozilla extended the interface WorkerUtils in their implementation 
with the atob/btoa functions.

I find them quite useful in that context, and would also encourage adding 
escape, unescape, encodeURI, decodeURI, encodeURIComponent, decodeURIComponent 
and many of the other global functions in the DOM environment which don't have 
any specific bindings to the DOM itself or manipulate documents, as that was a 
concern due to globals that are internally used by the DOM in some browsers.

Thank you.

Re: [XHR2] ArrayBuffer support added

[Charles Pritchard]

Following up on this older thread, Mozilla has added ArrayBuffer to 
their XHR object, though the documentation

is a little bare.

xhr.mozResponseArrayBuffer


On 2/4/2011 2:01 AM, Anne van Kesteren wrote:
On Thu, 03 Feb 2011 23:56:13 +0100, Charles Pritchard 
 wrote:
But in the present, we've got XMLHttpRequest, with CORS semantics, 
and all other manner of goodness.
EventSource seems to me, to have different use cases than the simpler 
XHR.


Yes, it is meant for streaming. XMLHttpRequest isn't really. (And 
EventSource will get CORS in due course.)



XHR is a pretty stable and well supported method, it seems that it'd 
be reasonably straightforward
to take the current good-will around that standard, and see if a 
second ArrayBuffer response type is warranted.


I rather wait until all the new features are more widely adopted and 
tested. Then we can see if they have been a success and if we need more.



One nice thing to come out of it, saving a large file to a disk via 
XHR and FileWriter would be made

much easier, with no need for temporary storage locations.

Even with blob saved to disk, it'd take a lot of special case 
optimizations to make it efficient to copy
that Blob to a new file. It'd likely require a copy, instead of 
what's likely wanted: writing the file once.


Developing this now could have a positive effect on a future 
EventSource standard.

[Bug 11978] Section: Abstract Problem: "this specification defines two mecahism for..." should read "mechanisms".

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11978

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution||FIXED

--- Comment #1 from Ian 'Hixie' Hickson  2011-03-04 00:26:45 UTC 
---
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.

-- 
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.

[Bug 12234] New: [IndexedDB] Integrate with the HTML5 event loop

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12234

   Summary: [IndexedDB] Integrate with the HTML5 event loop
   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: jo...@sicking.cc
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


We need to stop using terms like "asynchronously do X" and instead say things
like "queue a task to do X". This will make it clearer what happens
asynchronously or synchronously in relation to what.

-- 
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.

[Bug 11348] [IndexedDB] Overhaul of the event model

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11348

Jonas Sicking  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jo...@sicking.cc
 Resolution||FIXED

--- Comment #6 from Jonas Sicking  2011-03-04 00:06:32 UTC ---
This should now be FIXED!

-- 
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.

[Bug 12229] When a IDBKeyRange.bound's lower param is greater than the upper one, we probably should throw some exception

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12229

Jeremy Orlow  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
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.

[Bug 12233] New: We should add a method to compare two IndxedDB keys

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12233

   Summary: We should add a method to compare two IndxedDB keys
   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


We should add a method to compare two IndxedDB keys.  Right now it's rather
difficult to do so manually.

-- 
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.

CfC: to stop work on Programmable HTTP Caching and Serving spec; deadline March 10

[Arthur Barstow]

Hi All,

WebApps' "Programmable HTTP Caching and Serving" spec was last updated 
by Nikunj in January 2010. Since then, my attempt to determine the level 
of interest in this spec via the tread below (archived at [1]) received 
no real traction.


As such, this is a Call for Consensus to formally stop work on this 
spec. More specifically, the proposal includes:


1. Moving the spec from the PubStatus' active API Specifications table 
[2] to the "Specs NO Longer Active" table [3]


2. Marking its "Plans" data with "Work on the specification has ended"

3. Removing it from WebApps' charter the next time the charter is 
renewed (current charter ends June 2012)


Positive response to this CfC is preferred and encouraged and silence 
will be assumed to mean agreement with the proposal. The deadline for 
comments is March 10. Please send all comments to:


  public-webapps@w3.org

-Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0447.html
[2] http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications
[3] http://www.w3.org/2008/webapps/wiki/PubStatus#Specs_NO_Longer_Active


 Original Message 
Subject: 	[DataCache] Status and plans for Programmable HTTP Caching and 
Serving?

Date:   Fri, 5 Nov 2010 14:26:13 +0100
From:   Barstow Art (Nokia-CIC/Boston) 
To: 	public-webapps , Nikunj Mehta 
, Bernard Traversat , 
Julian Reschke , Mark Nottingham 





Hi All,

During WebApps' November 1 gathering at the TPAC, we discussed [Mins] 
the WG's "Programmable HTTP Caching and Serving" spec, last updated by 
Nikunj in January 2010 [DataCache].


During this discussion, I agreed to the following related actions:

ACTION-599 "Ask Nikunj to report the status and plans of Programmable 
Cache to public-webapps"

http://www.w3.org/2008/webapps/track/actions/599

ACTION-600 "Ask Oracle about their level of interest in Programmable Cache"
http://www.w3.org/2008/webapps/track/actions/600

ACTION-601 "Ask public-webapps about creating Use Cases and requirements 
of Program App Caches versus HTML5 App Cache"

http://www.w3.org/2008/webapps/track/actions/601

ACTION-602 "Contact julian reschke and Mark Nottingham about Data Cache"
http://www.w3.org/2008/webapps/track/actions/602

My short summary of this discussion is: it isn't clear if there is 
sufficient interest to continue this spec and if there is interest, what 
are the specific use cases it will address (i.e. use cases not addressed 
by HTML5 AppCache), and who is willing to commit to drive the spec forward.


-Art Barstow

[ tracker tags: ACTION-599, ACTION-600, ACTION-601, ACTION-602 ]

[Mins] http://www.w3.org/2010/11/01-webapps-minutes.html#item05
[DataCache] http://dev.w3.org/2006/webapi/DataCache/

Re: publish a new Working Draft of DOM Core; comment deadline March 2

[Anne van Kesteren]

On Thu, 03 Mar 2011 04:43:04 +0100, Shiki Okasaka  
 wrote:

I guess the reason behind this has been discussed around:

  http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0081.html

Actually what are the blocking issues why DOM Core does not state like,

  interface EventTarget {
...
  };
  interface Node : EventTarget ...

yet?


None, I think, so done:

  https://bitbucket.org/ms2ger/dom-core/changeset/5a0331350bed

Thanks!


--
Anne van Kesteren
http://annevankesteren.nl/

Re: [postmsg] Is HTML5 Web Messaging ready for Last Call Working Draft?

[Arthur Barstow]

Hi All - I just wanted to let people know that on February 28, Hixie and 
I had a brief exchange about this in #webapps:


[[
http://krijnhoetmer.nl/irc-logs/webapps/20110228

# [21:14]  ArtB: i'm always going to answer "yes" whenever you 
ask if anything is ready to go to LC, CR, REC, or whatnot. :-)

# [21:18]  Hixie: oh, no, not another W3C process discussion :-)
# [21:19]  We should probably avoid publishing an LC if you are 
about to check in important changes that would affect an implementation
# [21:20]  But I understand [at least I think I do :-)] your 
perspective on publishing
# [21:20]  i'm not aware of any pending important changes, but i 
have 1668 e-mails in my pending feedback folders dating from the past 4 
months or so, so i can make no guarantees

# [21:21]  oh, dear
# [21:21]  i can however guarantee that i won't make any changes 
that harm implementations without having their ok
# [21:21]  so whether it's in LC or REC or ED doesn't make any 
difference to me or the implementors as far as i can tell :-)

# [21:21]  Hixie - ok; good to hear!
]]

-AB

On Feb/28/2011 3:09 PM, ext Arthur Barstow wrote:

Hixie, All,

Is the HTML5 Web Messaging spec ready for Last Call Working Draft?

http://dev.w3.org/html5/postmsg/

If not, what must be done before it is ready for LC and what is the 
time frame to complete the work?


Bugzilla [1] reports one bug for this component without a Resolution 
and that bug is a simple editorial typo:


http://www.w3.org/Bugs/Public/show_bug.cgi?id=11978

-Art Barstow

[1] 
http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&; 
amp;short_desc=&product=WebAppsWG&component=Web+Messaging+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

Re: CfC: publish a new Working Draft of DOM Core; comment deadline March 2

[Arthur Barstow]

Hi All,

There is significant support for this CfC and in general, I tend to 
favor PEPO (publish early, publish often).


However, in this case, the group already agreed D3E is feature complete 
and it would be suboptimal (some have suggested harmful), for WebApps to 
publish a spec that conflicts/overlaps with D3E. Additionally, some 
members have been working on D3E for a relatively long time and they 
naturally want to preserve their investment.


Doug expressed [DS] willingness to change D3E (to align with DOM Core 
Events) if there is broad consensus for changes. In this spirit of 
cooperation, before a new WD of DOM Core is published, I think the next 
step is to do as Doug suggested and identify all D3E issues.


Anne asked [AvK] about the mechanism to use to identify issues. Unless 
Doug suggests otherwise, I recommend using a separate thread per issue 
on the www-dom mail list.


-Art Barstow

[DS] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0687.html
[AvK] 
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0722.html


On Feb/23/2011 11:20 AM, ext Arthur Barstow wrote:
Anne and Ms2ger (representing Mozilla Foundation) have continued to 
work on the DOM Core spec and they propose publishing a new Working 
Draft of the spec:


http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html

As such, this is a Call for Consensus (CfC) to publish a new WD of DOM 
Core. If you have any comments or concerns about this proposal, please 
send them to public-webapps by March 2 at the latest.


As with all of our CfCs, positive response is preferred and encouraged 
and silence will be assumed to be agreement with the proposal.


-Art Barstow

Re: [whatwg] set input.value when input element has composition string

[Ryosuke Niwa]

On Thu, Mar 3, 2011 at 7:47 PM, Makoto Kato  wrote:

> Hi, Niwa-san.
>
> On 2011/03/02 15:30, Ryosuke Niwa wrote:
>
>> You must have tested Chrome improperly.  We currently have a bug in
>> Chrome.  To see the bug, open the attached test and type "nihao" with
>> Chinese IME on Windows or Mac.  Then press down array key.  The text is
>> replaced by henhao but "henha" is still marked and looks as if I'm
>> compositing "henha" but if I continue to type "ma" still with IME, then I
>> observe that "henhaomao" is shown inside the input element.  Once this bug
>> is fixed, Chrome's behavior should match that of Safari 5.
>>
>
> Do you think Safari's way (ex. 2) is right?
>

In short, yes.

It is confused that each Web browser is different behavior for this . This
> is not good as interoperability. So I would like to decide the right
> behavior/specification when textbox.value = 'x'; that it has composition
> string.
>
> Also, some people says that it should not be canceled/removed even if value
> is changed by DOM.  Because composition string is un-committed string.


It seems that the "correct" behavior depends on the semantics.

Say I have typed a text "你好", then I decided to add 们 between 你 and 好 so I
put the caret / insertion point between the two and start typing "men" on
IME.  At this point website randomly replaces the entire value by "Hello".
 In that case, as a user, I wouldn't expect to have my uncommitted string
"men" after "Hello" because semantically speaking, my greeting message in
Chinese has entirely been replaced by one in English.  There's no point in
adding "men" at this point.

On the other hand, if I had just typed "你" and website replaced the value by
"你们" as I typed "hao" on IME, then having the uncommitted text after "你们"
makes sense and I'd like to keep the text because then I can just commit my
text to obtain "你们好".

- Ryosuke

Re: [whatwg] set input.value when input element has composition string

[Makoto Kato]

Hi, Niwa-san.

On 2011/03/02 15:30, Ryosuke Niwa wrote:
On Tue, Mar 1, 2011 at 5:18 PM, Makoto Kato > wrote:


On Safari 5, even if textbox has IME composition string, text into
textbox can be replaced by DOM/script.  But other browser's
behaviors are different, and this is no specification when textbox
has composition string.  Although IE, Chrome and Opera keep
composition string after value is replaced by DOM, each behavior
is different.

This is the result for this test on each browsers.  When textbox
has IME composition string such as ABCDEFG, then script
(textbox.value = "123";) is called, textbox becomes...

1. "123ABCDEFG" (ABCDEFG keeps composition state and caret is
after G).
2. "123" (composition string is removed).
3. "ABCDEFG" (ABCDEFG keeps composition state and caret is after G).

Which behavior is right?  1 is Opera 11, 2 is Safari 5, and 3 is
Chrome 10 and IE9.


You must have tested Chrome improperly.  We currently have a bug in 
Chrome.  To see the bug, open the attached test and type "nihao" with 
Chinese IME on Windows or Mac.  Then press down array key.  The text 
is replaced by henhao but "henha" is still marked and looks as if I'm 
compositing "henha" but if I continue to type "ma" still with IME, 
then I observe that "henhaomao" is shown inside the input element. 
 Once this bug is fixed, Chrome's behavior should match that of Safari 5.


Do you think Safari's way (ex. 2) is right?   I found some bugs on 
Chrome (and IE and Opera) when I test this, but I am not interesting 
about bugs.


It is confused that each Web browser is different behavior for this . 
This is not good as interoperability. So I would like to decide the 
right behavior/specification when textbox.value = 'x'; that it has 
composition string.


Also, some people says that it should not be canceled/removed even if 
value is changed by DOM.  Because composition string is un-committed string.


Niwa-san and folks, how do you think right design for this situation??


-- Makoto Kato

Re: [IndexedDB] Two Real World Use-Cases

[Keean Schupke]

On 3 March 2011 09:15, Joran Greef  wrote:

> Hi Jonas
>
> I have been trying out your suggestion of using a separate object store to
> do manual indexing (and so support compound indexes or index object
> properties with arrays as values).
>
> There are some problems with this approach:
>
> 1. It's far too slow. To put an object and insert 50 index records (typical
> when updating an inverted index) this way takes 100ms using IDB versus 10ms
> using WebSQL (with a separate indexes table and compound primary key on
> index name and object key). For instance, my application has a real
> requirement to replicate 4,000,000 emails between client and server and I
> would not be prepared to accept latencies of 100ms to store each object.
> That's more than the network latency.
>
> 2. It's a waste of space.
>
> Using a separate object store to do manual indexing may work in theory but
> it does not work in practice. I do not think it can even be remotely
> suggested as a panacea, however temporary it may be.
>
> We can fix all of this right now very simply:
>
> 1. Enable objectStore.put and objectStore.delete to accept a setIndexes
> option and an unsetIndexes option. The value passed for either option would
> be an array (string list) of index references.
>
> 2. The object would first be removed as a member from any indexes
> referenced by the unsetIndexes option. Any referenced indexes which would be
> empty thereafter would be removed.
>
> 3. The object would then be added as a member to any indexes referenced by
> the setIndexes option. Any referenced indexes which do not yet exist would
> be created.
>
> This would provide the much-needed indexing capabilities presently lacking
> in IDB without sacrificing performance.
>
> It would also enable developers to use IDB statefully (MySQL-like
> pre-defined schemas with the DB taking on the complexities of schema
> migration and data migration) or statelessly (See Berkeley DB with the
> application responsible for the complexities of data maintenance) rather
> than enforcing an assumption at such an early stage.
>
> Regards
>
> Joran Greef
>


Why would this be faster? Surely most of the time in inserting the 50
indexes is the search time of the index, and the JavaScript function call
overhead would be minimal (its only 50 calls)?

Cheers,
Keean.

Re: [IndexedDB] Two Real World Use-Cases

[Joran Greef]

Hi Jonas

I have been trying out your suggestion of using a separate object store to do 
manual indexing (and so support compound indexes or index object properties 
with arrays as values).

There are some problems with this approach:

1. It's far too slow. To put an object and insert 50 index records (typical 
when updating an inverted index) this way takes 100ms using IDB versus 10ms 
using WebSQL (with a separate indexes table and compound primary key on index 
name and object key). For instance, my application has a real requirement to 
replicate 4,000,000 emails between client and server and I would not be 
prepared to accept latencies of 100ms to store each object. That's more than 
the network latency.

2. It's a waste of space.

Using a separate object store to do manual indexing may work in theory but it 
does not work in practice. I do not think it can even be remotely suggested as 
a panacea, however temporary it may be.

We can fix all of this right now very simply:

1. Enable objectStore.put and objectStore.delete to accept a setIndexes option 
and an unsetIndexes option. The value passed for either option would be an 
array (string list) of index references.

2. The object would first be removed as a member from any indexes referenced by 
the unsetIndexes option. Any referenced indexes which would be empty thereafter 
would be removed.

3. The object would then be added as a member to any indexes referenced by the 
setIndexes option. Any referenced indexes which do not yet exist would be 
created.

This would provide the much-needed indexing capabilities presently lacking in 
IDB without sacrificing performance.

It would also enable developers to use IDB statefully (MySQL-like pre-defined 
schemas with the DB taking on the complexities of schema migration and data 
migration) or statelessly (See Berkeley DB with the application responsible for 
the complexities of data maintenance) rather than enforcing an assumption at 
such an early stage.

Regards

Joran Greef