Re: RfC: DAP's Contacts API Last Call Working Draft; deadline July 14
On Wed, Jun 15, 2011 at 7:47 PM, Arthur Barstow art.bars...@nokia.com 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
Re: RfC: DAP's Contacts API Last Call Working Draft; deadline July 14
On Thu, Jun 16, 2011 at 12:23 PM, Marcos Caceres marcosscace...@gmail.com wrote: On Wed, Jun 15, 2011 at 7:47 PM, Arthur Barstow art.bars...@nokia.com 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: [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: [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 timel...@gmail.com 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 host or i would like to get url and the proxy says here's a connection for host or here's the data for url. 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
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 p...@w3.org 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 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: [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 isra...@microsoft.com
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 {
sequenceDOMString 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: [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] Should deleteDatabase return IDBVersionChangeRequest?
On Wed, Jun 15, 2011 at 5:34 PM, Israel Hilerio isra...@microsoft.com wrote: On Wednesday, June 15, 2011 3:27 PM, Jonas Sicking wrote: On Wed, Jun 15, 2011 at 2:15 PM, Israel Hilerio isra...@microsoft.com 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
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 Thursday, June 16, 2011 4:49 PM, Jonas Sicking wrote: On Wed, Jun 15, 2011 at 5:34 PM, Israel Hilerio isra...@microsoft.com wrote: On Wednesday, June 15, 2011 3:27 PM, Jonas Sicking wrote: On Wed, Jun 15, 2011 at 2:15 PM, Israel Hilerio isra...@microsoft.com 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: 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
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. Why isn't this something the script can do? Q: Multiple EventSource objects to the same URI?
Re: [indexeddb] IDBIndex.getKey incorrect description.
On Tue, Jun 14, 2011 at 9:00 AM, Israel Hilerio isra...@microsoft.com 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
