Re: [indexeddb] IDBIndex.getKey incorrect description.
On Tue, Jun 14, 2011 at 9:00 AM, Israel Hilerio wrote: > The description for the IDBIndex.getKey tells us to use “the steps for > > retrieving a value from an index" as the operation. These steps seem to > deal > > with how to retrieve values and not keys. It seems, we need a new section > > similar to this one that explains how to retrieve a primary key from an > index. > > The main issue we are having is knowing what to return when there are no > > records that match the "key" parameter. For example, imagine that we > > create an index on an empty object store and immediately call getKey. We > > believe that this should call the onsuccess handler with a result set to > > undefined. This seems to match the spirit of the note under > > IDBIndex.getKey. > > I believe this will also affect the IDBIndexSync.getKey. > > Do you agree? I *think* things are correct as they are since the 'value' field of the records in an index contains keys for the object store. Compare to the "steps for retrieving a referenced value from an index" algorithm used by IDBIndex.get(). / Jonas
Server-Sent Events feedback
On Fri, 15 Apr 2011, Ian Clelland wrote: > > Section 4: > When close() is called on the EventSource object, the initial connection may > not have been established yet, or a reconnection could be scheduled for some > arbitrary time in the future (not currently being attempted). Fixed. > > Only if the user agent reestablishes the connection does the > > connection get opened anew! > > The link in this sentence unhelpfully just points back to the same > paragraph that it appears in. Should this just be taken to mean that if > the user agent isn't in a state of "having to re-establish the > connection", then it shouldn't attempt to re-open the connection? Yeah. I've removed the sentence, it doesn't actually add anything. > The way it is written, and emphasized, I read it several times, thinking > it was some kind of critical security measure, but after some thinking, > it seems just to be saying the same thing as the next paragraph: "Once > the user agent has failed the connection, it does not attempt to > reconnect". Indeed. I added both sentences back in 2009 because there were some difficulties getting the point across with some early implementations, but just the second sentence is probably enough. :-) > > When the user agent is required to dispatch the event, then the user > > agent must act as follows: > > > 1. If the data buffer is an empty string, set the data buffer and the > > event name buffer to the empty string and abort these steps. > > > 2. If the data buffer's last character is a U+000A LINE FEED (LF) > > character, then remove the last character from the data buffer. > > > 3. Otherwise, create an event that uses the MessageEvent interface, > > with the event name message, which does not bubble, is not cancelable, > > and has no default action. The data attribute must be set to the value > > of the data buffer, the origin attribute must be set to the Unicode > > serialization of the origin of the event stream's URL, and the > > lastEventId attribute must be set to the last event ID string of the > > event source. > > The word "Otherwise" does not belong at the beginning of point 3 (unless > a trailing LF aborts the message event). It may belong at the beginning > of point 2, but does not appear to be strictly required (as point 1 > aborts). Oops. Fixed. It was there because there used to be a step between 2 and 3 that aborted, but that step is commented out at the moment. > Q: Last-Event-ID HTTP Header > > What is the result of a proxy dropping the Last-Event-ID header? (I'm > assuming here that old or misconfigured caches may silently drop headers > which they do not recognize.) Is that a safe assumption? > It is only sent on a reconnection attempt, so the client has likely seen > some of the event stream. The server would see this as a new connection, > however. My reading of the proposal suggests that the server could start > the event stream from the beginning again, or that it could start > sending live events from the current time forward, possibly missing any > that occurred during the reconnection timeout, which might have been > sent had the header not been dropped. Yeah. Depends on the server. > There does not seem to be a requirement for the server to use an event > ID on the first message in the connection, and if it does not, then the > client would use its own lastEventId as the event ID for the first > message or messages in the stream (until the server uses an "id" field > to re-synchronize). It depends on how the script is written. > I would suggest that a server, if it uses IDs at all to identify events, > be encouraged to send an ID with at least the first message of any new > connection. I'd rather not add such a warning unless we know it's a real problem. > Q: Server-controlled termination of connection > Is there any method for the server to signal to the client that it has the > event stream has been permanently exhausted, and that it should close the > connection and not attempt to reconnect? Sure, just send an event that the script understands means "close me". > Short of an agreement by which an MessageEvent with a specific payload > informs the client that it should call close() on the EventSource > object, the only way I can see for the server to abort the connection is > to forcibly close the connection, and return an invalid Content-Type or > HTTP status code on a subsequent reconnection attempt. This would > require the server to be able to recognize the client, which may not be > possible, or to realize that the Last-Event-ID in the client request > represents the end of the stream, and force an error at that point. Seems easier to just have the script close the stream. > It might be useful to have an message field name which indicates that > the server wishes to close the connection (or that it is about to close > the connection) and the no further events will be sent at that URI.
Re: RfC: DAP's Contacts API Last Call Working Draft; deadline July 14
The correct URL is: http://www.w3.org/TR/2011/WD-contacts-api-20110616/ On Jun/15/2011 1:47 PM, Arthur Barstow wrote: On June 16, the Device API group will publish a Last Call Working Draft of its Calendar API spec: http://www.w3.org/TR/2010/WD-contacts-api-20110616/ Individuals are encouraged to provide individual feedback directly to DAP via their public list: public-device-a...@w3.org If anyone in WebApps WG wants to propose an official WG response, please do so in reply to this email as soon as possible so the WG members can discuss the reply. The comment deadline is July 14. -AB
RE: [indexeddb] Should deleteDatabase return IDBVersionChangeRequest?
On Thursday, June 16, 2011 4:49 PM, Jonas Sicking wrote: > On Wed, Jun 15, 2011 at 5:34 PM, Israel Hilerio > wrote: > > On Wednesday, June 15, 2011 3:27 PM, Jonas Sicking wrote: > >> On Wed, Jun 15, 2011 at 2:15 PM, Israel Hilerio > >> > >> wrote: > >> > IDBFactory.deleteDatabase can be called without ever invoking the > >> > IDBDatabase.setVersion and requires a VERSION_CHANGE transaction > >> > for it to happen. Unfortunately, there is no way for the caller of > >> > deleteDatabase to receive a blocked event because IDBRequest > >> > doesn't define an onblocked event handler. Not having this > >> > functionality will prevent the deleteDatabase caller from > >> > understanding that someone has the DB locked and that the request > cannot be honored. > >> > > >> > > >> > > >> > To support this scenario we would have to change the return value > >> > of IDBFactory.deleteDatabase to return an IDBVersionChangeRequest. > >> > This will allow the caller to register an onblocked event handler > >> > and receive an event when the DB is locked by someone else. > >> > >> Agreed! > >> > >> > In addition, we may want to update the text in "4.10 Database > >> > deletion steps" step #6 from "fire a blocked event at request" to > >> > "fire a block event at version change request". > >> > >> Hmm.. isn't "request" just defined to be the variable used throughout > >> the algorithm to fire events at? It's more like a name of a variable > >> than a type. If you look at the VERSION_CHANGE transaction steps they > >> also simply use "request". > >> > >> / Jonas > > > > Great! > > If everyone else is okay with it, I'll work with Eliot to change the > > signature of > the method and we'll keep section 4.10 as is. > > Thanks, > > Sounds great! You probably need to mention in the text somewhere too that > the created request should implement the IDBVersionChangeRequest > interface. Look at how setVersion does it. > > / Jonas Sounds good, we'll do. Israel
RE: [indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters
On Thursday, June 16, 2011 3:09 PM, Cameron McCormack wrote:
> Israel Hilerio:
> > Great! I will work with Eliot to update the spec for the two APIs
> > below, including their Synchronous counterparts, with:
> > ---
> > dictionary IDBDatabaseOptionalParameters {
> >DOMString keyPath = null;
>
> That would need to be
>
> DOMString? keyPath = null;
>
> (or else just write “DOMString keyPath;” and state in prose what it means if
> the dictionary member was not specified).
>
> --
> Cameron McCormack ≝ http://mcc.id.au/
Good catch! I will make sure add:
DOMString? keyPath = null;
Israel
Re: [indexeddb] Should deleteDatabase return IDBVersionChangeRequest?
On Wed, Jun 15, 2011 at 5:34 PM, Israel Hilerio wrote: > On Wednesday, June 15, 2011 3:27 PM, Jonas Sicking wrote: >> On Wed, Jun 15, 2011 at 2:15 PM, Israel Hilerio >> wrote: >> > IDBFactory.deleteDatabase can be called without ever invoking the >> > IDBDatabase.setVersion and requires a VERSION_CHANGE transaction for >> > it to happen. Unfortunately, there is no way for the caller of >> > deleteDatabase to receive a blocked event because IDBRequest doesn't >> > define an onblocked event handler. Not having this functionality will >> > prevent the deleteDatabase caller from understanding that someone has >> > the DB locked and that the request cannot be honored. >> > >> > >> > >> > To support this scenario we would have to change the return value of >> > IDBFactory.deleteDatabase to return an IDBVersionChangeRequest. This >> > will allow the caller to register an onblocked event handler and >> > receive an event when the DB is locked by someone else. >> >> Agreed! >> >> > In addition, we may want to update the text in "4.10 Database deletion >> > steps" step #6 from "fire a blocked event at request" to "fire a block >> > event at version change request". >> >> Hmm.. isn't "request" just defined to be the variable used throughout the >> algorithm to fire events at? It's more like a name of a variable than a >> type. If >> you look at the VERSION_CHANGE transaction steps they also simply use >> "request". >> >> / Jonas > > Great! > If everyone else is okay with it, I'll work with Eliot to change the > signature of the method and we'll keep section 4.10 as is. > Thanks, Sounds great! You probably need to mention in the text somewhere too that the created request should implement the IDBVersionChangeRequest interface. Look at how setVersion does it. / Jonas
Re: [indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters
Israel Hilerio:
> Great! I will work with Eliot to update the spec for the two APIs
> below, including their Synchronous counterparts, with:
> ---
> dictionary IDBDatabaseOptionalParameters {
>DOMString keyPath = null;
That would need to be
DOMString? keyPath = null;
(or else just write “DOMString keyPath;” and state in prose what it
means if the dictionary member was not specified).
--
Cameron McCormack ≝ http://mcc.id.au/
RE: [indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters
On Monday, June 13, 2011 1:17 PM, Jonas Sicking wrote:
> On Mon, Jun 13, 2011 at 1:00 PM, Israel Hilerio
> wrote:
> > On Tuesday, June 07, 2011 4:53 PM, Cameron McCormack wrote:>
> timeless:
> >> > would having a field: "mandatory" which indicates which arguments
> >> > (or feature names) must be supported by the implementation assuage
> >> > your concern?
> >> >
> >> > createObjectStore("car", { mandatory: ["foreignKeys"], keyPath:
> >> > "id",
> >> > foreignKeys: [{keyPath: "brand", objectStore: "car-brands"}]);
> >>
> >> Certainly that would work for this case, and I kind of like it.
> >>
> >> I feel like there would be instances where you would need this
> >> fail-if- property-not-specified behaviour and others where would
> >> don’t need it, hence we needn’t require all unrecognised properties to
> cause the call to fail.
> >> If we agree with that sentiment, then I think something like the
> >> above is the way to go. A question would be whether we want to have
> >> some IDL-level support for JS objects specifying properties that need
> >> to be recognised for the call to succeed, or whether it’s OK for
> >> individual specifications like IndexedDB to define their own, like
> >>
> >> dictionary ObjectStoreCreationOptions {
> >> sequence mandatory;
> >> DOMString keyPath;
> >> // ...
> >> };
> >>
> >> --
> >> Cameron McCormack ≝ http://mcc.id.au/
> >
> > Timeless,
> >
> > We like your idea. Following is my understanding of it. Also, we prefer
> > the
> term "required" instead of "mandatory", since "required" would be a way a
> dev could express what they expect the platform to support (i.e. what their
> implementation requires).
>
> >
> > Given the current IDB requirement to support "keyPath" and
> "autoIncrement" valid properties on optionalParameters, this is how I see
> devs using the proposed solution:
> >
> > Example1:
> > createObjectStore("car", { keyPath: "id", autoIncrement: true, other:
> > value, required: ["keyPath", "autoIncrement"]});
> >
> > Example2:
> > createObjectStore("car", { keyPath: "id", other: value, required:
> > ["keyPath"]});
> >
> > Example3:
> > createObjectStore("car", { autoIncrement: true, other: value,
> > required: ["autoIncrement"]});
> >
> > Example4:
> > createObjectStore("car", { autoIncrement: true, other: value,
> > required: ["other"]});
> >
> > In all of these examples, the additional property called "other" will not
> affect the execution of createObjectStore. In addition, the system will be
> responsible for validating that the only two supported "required" fields
> would be "keyPath" and "autoIncrement". Therefore, Example #4 will fail
> because "other" is not a supported required field.
> >
> > Is this what you were thinking?
>
> For what it's worth, I've talked to various people here at mozilla about this
> issue. Everyone else feels that while it's unfortunate that users which expect
> a v2 API might silently get a different behavior on a v1 API, it's a even
> bigger
> complexity to try to detect absence of unrecognized properties.
>
> So I'll relent and go with that opinion.
>
> I think the required property is an interesting idea, but not something that
> we need until there is a v2 which introduces properties that a v1
> implementation won't need.
>
> So lets just use the dictionary syntax as defined by WebIDL with no extra
> fancy stuff.
>
> / Jonas
Great! I will work with Eliot to update the spec for the two APIs below,
including their Synchronous counterparts, with:
---
dictionary IDBDatabaseOptionalParameters {
DOMString keyPath = null;
boolean autoIncrement = false;
};
IDBDatabase:
IDBObjectStore createObjectStore (in DOMString name, in optional
IDBDatabaseOptionalParameters optionalParameters) raises (IDBDatabaseException);
This will allow a developer to use this function in the following way:
var dbOptionalParams = { keyPath: "name" };
var name = “myObjectStore”;
var index = x.createObjectStore(name, dbOptionalParams); //This will default
the value of autoIncrement to false.
---
dictionary IDBIndexOptionalParameters {
boolean unique = false;
boolean multientry = false;
};
IDBObjectStore:
IDBIndex createIndex (in DOMString name, in DOMString keyPath, in optional
IDBIndexOptionalParameters optionalParameters) raises (IDBDatabaseException);
This will allow a developer to use this function in the following way:
var indexOptionalParams = { unique: true };
var name = “myIndex”;
var keyPath = “name”;
var index = x. createIndex (name, keyPath, indexOptionalParams); //This will
default the value of multientry to false.
Israel
Re: [Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior
On Thu, 2011-06-16 at 11:59 -0700, James Robinson wrote: > That text requires the storage mutex, which has not and will not be > implemented by any vendors, let alone 2 interoperable implementations, > so it seems rather doomed. Where does it do that? My only intent was to fix 12111 and nothing else... Philippe
Re: [Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior
That text requires the storage mutex, which has not and will not be implemented by any vendors, let alone 2 interoperable implementations, so it seems rather doomed. - James On Jun 16, 2011 8:58 AM, "Philippe Le Hegaret" wrote: > Art wrote: >> All - given that addressing 12111 is a low priority for Ian, one way >> forward is for someone else to create a concrete proposal. > > Here is a concrete proposal: > http://www.w3.org/2011/06/Web%20Storage.html > > Philippe > > >
Re: [Bug 12965] New: Problem: I want to perform DNS queries from a HTML5 app, but the networking functions available are too restrictive to build a stub resolver. Why: DNS is not just for machines -
On Wed, Jun 15, 2011 at 11:32 PM, timeless wrote: > Some computers live behind proxies which do not provide for client > based dns lookups. instead a client tells the proxy "i would like to > talk to " or "i would like to get " and the proxy says > "here's a connection for " or "here's the data for ". You mean there are clients that don't have access to any DNS, only HTTP proxies? I haven't heard of that, but it wouldn't surprise me. > An API for doing DNS work will not work in such situations. What you > will probably have is something that "usually works" but fails on any > interesting corporate network, which is unfortunate. Such a network would also fail for WebSockets, SPDY, or lots of other interesting things. That's not a reason to not create such features. Some features aren't going to work for some users. > This is the general reason that DNS APIs aren't exposed. The other > reason is that DNS can easily include private information and browsers > aren't particularly good at understanding what is private and > shouldn't be exposed to web apps. That's my bigger concern. Internal corporate DNS could have lots of interesting info. You might also be able to leverage this for some type of cache poisoning, although I can't think of a specific scenario off the top of my head.
Re: [Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior
Art wrote: > All - given that addressing 12111 is a low priority for Ian, one way > forward is for someone else to create a concrete proposal. Here is a concrete proposal: http://www.w3.org/2011/06/Web%20Storage.html Philippe
Re: RfC: DAP's Contacts API Last Call Working Draft; deadline July 14
On Thu, Jun 16, 2011 at 12:23 PM, Marcos Caceres wrote: > On Wed, Jun 15, 2011 at 7:47 PM, Arthur Barstow wrote: >> On June 16, the Device API group will publish a Last Call Working Draft of >> its Calendar API spec: > >> http://www.w3.org/TR/2010/WD-contacts-api-20110616/ > > Link should be: Doh, c/p error... I mean: http://www.w3.org/TR/contacts-api/ I got confused because the link was returning a 404. >> Individuals are encouraged to provide individual feedback directly to DAP >> via their public list: >> >> public-device-a...@w3.org >> >> If anyone in WebApps WG wants to propose an official WG response, please do >> so in reply to this email as soon as possible so the WG members can discuss >> the reply. >> >> The comment deadline is July 14. >> >> -AB >> >> >> > > > > -- > Marcos Caceres > http://datadriven.com.au > -- Marcos Caceres http://datadriven.com.au
Re: RfC: DAP's Contacts API Last Call Working Draft; deadline July 14
On Wed, Jun 15, 2011 at 7:47 PM, Arthur Barstow wrote: > On June 16, the Device API group will publish a Last Call Working Draft of > its Calendar API spec: > http://www.w3.org/TR/2010/WD-contacts-api-20110616/ Link should be: http://www.w3.org/TR/2010/WD-contacts-api-20101209/ > Individuals are encouraged to provide individual feedback directly to DAP > via their public list: > > public-device-a...@w3.org > > If anyone in WebApps WG wants to propose an official WG response, please do > so in reply to this email as soon as possible so the WG members can discuss > the reply. > > The comment deadline is July 14. > > -AB > > > -- Marcos Caceres http://datadriven.com.au
