gmane.org.w3c.appformats

[IndexedDB] IDBRequest.onerror for DataCloneError and DataError

Kyaw Tun — 2013-05-20T01:37:04

Sorry for reposting again for
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0422.html Perhaps
I am not well explain enough.

In put and add method of object store and index, DataCloneError and
DataError are immediately throw before executing IDBRequest. It seems good
that exception are throw immediately, but in practical use case, these
exception are in async workflow (inside transaction callback). Exception
break the async workflow, (of course, it depending on usage design
pattern).

DataCloneError and DataError are preventable in most situation. But
sometimes tricky. We even want database to handle these errors like
database constraint. The logic will be much simpler if DataCloneError and
DataError cause to invoke IDBRequest.onerror rather than exception.

Re: [IndexedDB] request feedback on IDBKeyRange.inList([]) enhancement

Kyaw Tun — 2013-05-20T01:25:59

IDBKeyRange.inList looks practically useful, but it can be achieve
continue (continuePrimary) cursor iteration. Performance will be
comparable except multiple round trip between js and database.

Querying by parallel multiple get in a single transaction should also
be fast as well.

Additionally IDBKeyRange.inList violate contiguous key range nature of
IDBKeyRange. It is assumed in some use case, like checking a key in
the key range or not. If this feature are to be implemented, it should
not mess with IDBKeyRange, but directly handle by index batch request.

Ignoring deplicating keys is not a useful feature in query. In fact, I
will like result be respective ordering of given key list.

Kyaw Tun

Re: A very preliminary draft of a URL spec

Tab Atkins Jr. — 2013-05-19T23:45:59

On Tue, May 14, 2013 at 4:24 AM, Charles McCathie Nevile
<chaals< at >yandex-team.ru> wrote:

As Anne noted, it's the edge cases that are *important* to resolve.
We already have specs that define a bunch of the easy stuff, but they
leave off the edge cases that allow interoperability.


This is the work of an Intro section, or at most an Explainer
document.  Either would be welcome!  The URL spec accepts pull
requests.  ^_^


URLs are old enough that this is less likely to be an issue than for
many techs being specified today.  Regardless, though, this is
something that can be solved more easily by leaning on existing W3C
process - spin up a community group, occasionally copy over a snapshot
of the URL spec, and publish it as a Final Specification (or whatever
the name is).  This gives you patent coverage, and is basically
mechanical.


There is no process issue with normatively referring to WHATWG specs.
Even if there was, see above for an easier solution to the problem
than independently writing a parallel spec

[IndexedDB] request feedback on IDBKeyRange.inList([]) enhancement

Ben Kelly — 2013-05-17T21:37:24

Hello all,

Recently I've been working on a mobile application that makes heavy use of IndexedDB.  In particular, there are times when this app must query a potentially large, non-consecutive list of keys.  Currently (to my knowledge) the IndexedDB API requires that this be done via separate get() calls.  Due to some performance issues I investigated enhancing the IndexedDB API to allow the list of keys to be queried in a single request.  The resulting changes seem to show significant performance improvement on the mozilla mobile platform.

I would like to get your feedback and input on this API change.

The enhancement essentially adds an inList() function to IDBKeyRange.  Similar to the other factory methods on IDBKeyRange, this returns an object which can be used to query a matching set of keys.  The inList() function takes an array of keys to match against.  In practice it would look like the following:

  var keyRange = IDBKeyRange.inList(['key-1', 'key-2', 'key-3']);
  var request = index.openCursor(ke

Re: Re: Re: [XHR] anonymous flag

Hallvord Reiar Michaelsen Steen — 2013-05-18T23:02:00






Good point.





Simplest possibility seems to be "undefined" if not set, true or false respectively if it was set. Of course this doesn't reflect whether credentials will be sent in the request or not - but that doesn't really happen today either, we don't automagically make it return "true" for same-origin and "false" for cross-origin requests, so it's not much of a change. Most capability detection I've seen uses the sensible "'withCredentials' in xhr" form which will still work.

Re: Re: [XHR] anonymous flag

Jonas Sicking — 2013-05-18T20:58:35

On Sat, May 18, 2013 at 1:43 PM, Hallvord Reiar Michaelsen Steen
<hallvord< at >opera.com> wrote:

It seems confusing to anyone who reads the value. What would it return
in the various situations? I.e. before and after .open() has been
called, and if .open() was called with a cross-origin URL or not.

/ Jonas

Re: Re: [XHR] anonymous flag

Hallvord Reiar Michaelsen Steen — 2013-05-18T20:43:10




Possibly, but I find it unlikely - if it's set, it's most likely usually set to "true", not "false", and it's also most likely rarely set for same-origin requests. Wonder how hard it would be to ship a test in some beta- or preview build of some browser..? 8-)




To whom? "Defaults to true for same-origin, false for cross-origin, can be set to override" seems to give authors a behaviour that's relatively intuitive. (Authors would not really have to consider the odd tri-state underpinnings, it still looks like a boolean except with a variable default behaviour).


It might be weird and confusing to implement though..

Re: Overlap between StreamReader and FileReader

Jonas Sicking — 2013-05-18T19:46:51

It's not exactly an event stream since the exact events isn't what
matters here. I.e. you'll get different events in different
implementations, and there are no guarantees that the events
themselves will be meaningful.

But yeah, I agree it's not representing a value and so it's an abuse
of Future's semantics.

/ Jonas

Re: [XHR] anonymous flag

Anne van Kesteren — 2013-05-18T14:42:07

On Sat, May 18, 2013 at 8:41 AM, Hallvord Reiar Michaelsen Steen
<hallvord< at >opera.com> wrote:

I suspect that would break sites. Making a boolean a tri-state with a
default depending on an external variable is also super confusing.


--
http://annevankesteren.nl/

Re: Overlap between StreamReader and FileReader

Anne van Kesteren — 2013-05-18T14:36:18

Yeah, futures represent a value. This is an event stream (that does
not keep track of history).


--
http://annevankesteren.nl/

Re: Overlap between StreamReader and FileReader

Takeshi Yoshino — 2013-05-18T08:27:40


This is also clear read-only-once interface as well as onmessage() approach
because there's no attribute to accumulate the result value. The fact that
the argument for accept callback is void strikes at least me that the value
passed to progress callback is not an accumulated result but each chunk
separately.

As the state transition of Stream would be simple enough to match Future, I
think technically it's ok and even better to employ it than "readyState +
callback" approach.

But is everyone fine with making it mandatory to get used to programming
with Future to use Stream?

Re: Overlap between StreamReader and FileReader

Takeshi Yoshino — 2013-05-18T07:48:50


I'd name it "asStream". readStream operation here isn't intended to do any
"read", i.e. moving data between buffers, (like ArrayBufferView for
ArrayBuffer) right?

Or it's gonna clone the Blob's contents and wrap with the Stream interface
as we cannot "discard" contents of a Blob and it'll be inconsistent with
the semantics (implication?) we're going to give to the Stream interface?

Re: [XHR] anonymous flag

Hallvord Reiar Michaelsen Steen — 2013-05-18T07:41:22

BTW - have you considered allowing setting withCredentials to "false" for same-origin resources?

As-is, the author may not expect what happens if she sets withCredentials to false, makes a cross-origin request, and the remote server redirects to a same-origin URL. Now cookies will be sent to that resource, as far as I can tell. This is unexpected, and may well give authors a false sense of security, believing they have safeguarded against certain CSRF / confused deputy attacks when they haven't.

The answer is of course creating an anonymous request instead, but the example illustrates the potential for confusion when we have two apparently similar ways to achieve a "don't send credentials " state in the API. 

If withCredentials were a tri-state flag, where unset would default to false on cross-origin and true on same-origin requests, I think this would be much clearer. (You might think changing this is too late, but the only effect of the change would be respecting instead if ignoring an explicit withCred

Re: Overlap between StreamReader and FileReader

Jonas Sicking — 2013-05-18T04:56:58

Actually, we could even get rid of the ChunkedData interface and do
something like

interface Stream {
  AbortableProgressFuture<ArrayBuffer> readBinary(optional unsigned
long long size);
  AbortableProgressFuture<String> readText(optional unsigned long long
size, optional DOMString encoding);
  AbortableProgressFuture<Blob> readBlob(optional unsigned long long size);

  AbortableProgressFuture<void> readBinaryChunked(optional unsigned
long long size);
  AbortableProgressFuture<void> readTextChunked(optional unsigned long
long size);
};

where the ProgressFutures returned from
readBinaryChunked/readBinaryChunked delivers the data in the progress
notifications only, and no data is delivered when the future is
actually resolved. Though this might be abusing Futures a bit?

/ Jonas

Re: Overlap between StreamReader and FileReader

Jonas Sicking — 2013-05-18T04:38:11

I figured I should chime in with some ideas of my own because, well, why not :-)

First off, I definitely think the semantic model of a Stream shouldn't
be "a Blob without a size", but rather "a Blob without a size that you
can only read from once". I.e. the implementation should be able to
discard data as it passes it to a reader.

That said, many Stream APIs support the concept of a "T". This enables
splitting a Stream into two Streams. This enables having multiple
consumers of the same data source. However when a T is created, it
only returns the data that has so far been unread from the original
Stream. It does not return the data from the beginning of the stream
since that would prevent streams from discarding data as soon as it
has been read.

If we are going to have a StreamReader API, then I don't think we
should model it after FileReader. FileReader unfortunately followed
the model of XMLHttpRequest (based on request from several
developers), however this is a pretty terrible API, and I believe we
c

Re: [XHR] anonymous flag

Hallvord Reiar Michaelsen Steen — 2013-05-17T20:42:35

Den 17. mai 2013 kl. 11:53 skrev Anne van Kesteren <annevk< at >annevk.nl>:


I am trying.  "Confused deputy" is a general and somewhat abstract class of issues. The only way I know to "consider" such an abstraction carefully is to try to translate it to real world scenarios, then discuss those, so that's what I have been trying to do. That approach also seems to match the "use cases, use cases" approach spec authors generally aim for. 


I hope a few more people will chime in, sure. I would like to assure anyone who considers voicing an opinion that I will not consider your participation in the discussion a waste of MY time.
Hallvord

[Bug 19771] Need way to determine what keys are supported on device.

2013-05-17T16:42:19

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19771

Gary Kacmarcik <garykac< at >google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |garykac< at >google.com,
                   |                            |public-webapps< at >w3.org
          Component|DOM3 Events                 |UI Events
           Assignee|travil< at >microsoft.com        |garykac< at >google.com

--- Comment #2 from Gary Kacmarcik <garykac< at >google.com> ---
We're trying to do something similar with queryKeyCaps in UI Events.

Since this certainly won't be part of D3E at this point, I'm changing the
component to "UI Events" so we can consider it for that spec.

Re: Overlap between StreamReader and FileReader

Takeshi Yoshino — 2013-05-17T12:02:56



Forgetting File API completely, for example, ... how about simple socket
like interface?

// Downloading big data

var remaining;
var type = null;
var payload = '';
function processData(data) {
  var offset = 0;
  while (offset < data.length) {
    if (!type) {
      var type = data.substr(offset, 1);
      remaining = payloadSize(type);
    } else if (remaining > 0) {
      var consume = Math.min(remaining, data.length - offset);
      payload += data.substr(offset, consume);
      offset += consume;
    } else if (remaining == 0) {
      if (type == FOO) {
        foo(payload);
      } else if (type == BAR) {
        bar(payload);
      }
      type = null;
    }
  }
}

var client = new XMLHttpRequest();
client.onreadystatechange = function() {
  if (this.readyState == this.LOADING) {
    var responseStream = this.response;
    responseStream.setBufferSize(1024);
    responseStream.ondata = function(evt) {
      processData(evt.data);
      // Consumed data will be invalidated and memory used for the da

Re: Overlap between StreamReader and FileReader

Anne van Kesteren — 2013-05-17T11:27:26

I'm glad we're all getting on the same page now. I think there might
be use cases for a Blob without size (i.e. where you do not discard
the data after consuming) which is what Stream seems to be today, but
I'm not sure we should call that Stream.

And I think for XMLHttpRequest at least we want an API where data can
be discarded once processed so you do not have to keep multi-megabyte
sound files on disk if all you want is to provide a (potentially
post-processed) live stream.



Yeah that seems about right.



I haven't really thought about what I'd use it for, but I looked at
e.g. Dart and it seems to have a concept of broadcasted streams. Maybe
analyze the incoming bits in one function and in another you'd process
the incoming data and do something with it. Above all though it needs
to be clear what happens and for IO streams where you do not want to
keep all the data around (e.g. unlike the current Streams API) it's a
question that needs answering.


--
http://annevankesteren.nl/

Re: Overlap between StreamReader and FileReader

Takeshi Yoshino — 2013-05-17T11:09:19

Sorry, I just took over this work and so was misunderstanding some point in
the Streams API spec.

On Fri, May 17, 2013 at 6:09 PM, Anne van Kesteren <annevk< at >annevk.nl> wrote:



Yes. "Read data is automatically released" model is simple and good.

I thought the spec is clear about this but sorry it isn't. In the spec we
should say that StreamReader invalidates consumed data in Stream and buffer
for the invalidated bytes will be released at that point. Right?




I wanted to understand clearly what you meant by "discard" in your posts. I
wondered if you were suggesting that we have some method to skip incoming
data without creating any object holding received data. I.e. something like

s.skip(10);
s.readFrom(10);

not like

var useless_data_at_head_remaining = 256;
ondata = function(evt) {
  var bytes_received = evt.data.size();
  if (useless_data_at_head_remaining > bytes_received) {
    useless_data_at_head_remaining -= bytes_received;
    return;
  }

  processUsefulData(evt.data.slice(uselesss_data_at_he

Re: [XHR] anonymous flag

Anne van Kesteren — 2013-05-17T10:36:19

On Fri, May 17, 2013 at 11:24 AM, Charles McCathie Nevile
<chaals< at >yandex-team.ru> wrote:

We have been over this many times in the discussions over CORS and
UMP, including whether or not we care about confused deputy attacks
and ambient authority. At the time we decided we did which is why we
offered this feature.

In addition, there's been requests to have more control over whether
cookies are transmitted (as they take up space) and as to whether the
Referer header is included in requests (not the same as setting its
value to null, which is not what setRequestHeader() can be used for
anyway, as it's for additional headers, not controlling existing
ones). See e.g. http://wiki.whatwg.org/wiki/Meta_referrer for a
feature that seems to be getting some traction. Whether these should
be combined or not is unclear to me (UMP needs both).

I don't really feel it's responsible to remove this feature at this
point without anyone involved in the original discussion speaking up.
But then since it's not implemented mayb