Re: Can IndexedDB depend on JavaScript? (WAS: [Bug 9793] New: Allow dates and floating point numbers in keys)
On Sun, May 23, 2010 at 4:06 AM, Maciej Stachowiak m...@apple.com wrote: On May 22, 2010, at 3:58 AM, Jeremy Orlow wrote: Even though no one is currently considering implementing this outside of JavaScript land and even though it'll limit us some and making speccing harder, I think it'd be a mistake to depend on JavaScript. And, as far as I can tell, the whole point of WebIDL is to not depend on one single language. And I can't think of any others that do. WebKit exposes Web APIs as part of the native API for embedders, this includes Objective-C and GObject bindings. There have also been suggestions to add bindings for languages such as Python, Java or Ruby. I think interfaces for Web platform APIs should remain language-agnostic to the degree possible. For the date issue specifically, we should consider adding a Web IDL date type which could map to JavaScript Date objects and potentially native date types for other languages, and something language agnostic for ether languages. Cameron/Sam would you be willing to add something like this to WebIDL? I have no idea what the spec language would look like otherwise I'd draft up some proposed text. J
RE: [cors] Simplify CORS Headers (ISSUE-89)
In IE, we only support Access-Control-Allow-Origin and combining with other values (albeit optional ones) that we don't support might be misleading. It also introduces some additional parsing that changes the behaviour from a simple comparison to a more complex parse and then compare. We wouldn't be able to drop support for the current header so we'd need to support both and have a precedence order for which wins if both headers are present with different values. It's unlikely we'd issue a patch for IE8 unless there was strong customer demand and even if we did, there's no guarantee that it would be installed so services would still need to send both headers. I'm not all that keen on changing the names at this point either. Adrian. On Friday, May 14, 2010 10:19 AM, Arthur Barstow wrote: Simpler and/or shorter would indeed be good, although it may be too late. Jonas, IE Guys (Chris, Adrian, ...) - what is your input on this issue? -Art Barstow On May 13, 2010, at 3:39 AM, ext Maciej Stachowiak wrote: On May 6, 2010, at 5:30 PM, Anne van Kesteren wrote: I suggest we merge Access-Control-Allow-Origin, Access-Control- Allow-Credentials, and Access-Control-Max-Age into a new header, named CORS. The syntax of this new header would be: CORS : credentials? origin-value delta-seconds? I'm not that keen on changing the names, but if we do, I think CORS might be a bit mysterious by itself as a header name. Here's another set of naming suggestions, if we do go down the renaming path (which for the record I'd rather not): CORS == Allow-Access or Expose-Response CORS-Methods == Allow-Methods CORS-Headers == Allow-Headers (or Allow-Request-Headers) CORS-Preflight == can't think of a better name for this new header to expose more response headers == Expose-Headers (or Expose-Response-Headers) Regards, Maciej
Re: Can IndexedDB depend on JavaScript? (WAS: [Bug 9793] New: Allow dates and floating point numbers in keys)
On May 24, 2010, at 3:30 AM, Jeremy Orlow wrote: On Sun, May 23, 2010 at 4:06 AM, Maciej Stachowiak m...@apple.com wrote: On May 22, 2010, at 3:58 AM, Jeremy Orlow wrote: Even though no one is currently considering implementing this outside of JavaScript land and even though it'll limit us some and making speccing harder, I think it'd be a mistake to depend on JavaScript. And, as far as I can tell, the whole point of WebIDL is to not depend on one single language. And I can't think of any others that do. WebKit exposes Web APIs as part of the native API for embedders, this includes Objective-C and GObject bindings. There have also been suggestions to add bindings for languages such as Python, Java or Ruby. I think interfaces for Web platform APIs should remain language-agnostic to the degree possible. For the date issue specifically, we should consider adding a Web IDL date type which could map to JavaScript Date objects and potentially native date types for other languages, and something language agnostic for ether languages. Cameron/Sam would you be willing to add something like this to WebIDL? I have no idea what the spec language would look like otherwise I'd draft up some proposed text. I am happy to add language for a Date type. -Sam
Re: Do we need to rename the Origin header?
Adam Barth wrote on 7/16/2009 10:38 AM: On Thu, Jul 16, 2009 at 8:47 AM, Bil Corryb...@corry.biz wrote: I think you mean everything will NOT be privacy-sensitive except non-XHR GETs. I don't think we've quite settled on exactly what will be privacy sensitive. It's most likely that POSTs and XHR will not be and that hyperlinks and image loads will be. The goal is to harmonize with the Mozilla proposal. I haven't been following the progress of this, has privacy-sensitive been defined in HTML5 yet? The only reference I could find was in 2.6 Fetching Resources: ---8--- For the purposes of the Origin header, if the fetching algorithm was explicitly initiated from an origin, then the origin that initiated the HTTP request is origin. Otherwise, this is a request from a privacy-sensitive context. [ORIGIN] (from: http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#fetching-resources) ---8--- - Bil
Re: [IndexedDB] Re: [Bug 9769] New: IDBObjectStoreRequest/Sync.put should be split into 3 methods
On Fri, May 21, 2010 at 6:59 PM, Kris Zyp k...@sitepen.com wrote:
or to use something like
put(record, {forbidOverwrite: true}); // don't overwrite
put(record, {onlyOverwrite: true}); // must overwrite/update
put(record, {}); or put(record); // can do either
or some such.
However ultimately I feel like this directive will be used often
enough that it makes sense to create explicit API for it. The
implementation overhead of separate functions is really not that
big, and I can't see any usage overhead?
I am not too concerned about the implementation. But, as we been using
this API in SSJS, we have been increasingly using a wrapper pattern,
wrapping low-level stores with additional functionality that exposes
the same API. Wrappers add functionality such as caching, data change
notifications, extra validation, and so. The more methods that are
exposed the more difficult it is wrap stores.
Couldn't you always simply call addOrModify (or whatever we'll end up
calling it)? Given that neither localStorage or WebSQLDatabase
supports 'forbid overwrite' inserts it seems like this should work?
Don't assume that the API will only be consumed.
Definitely. The API is definitely intended to be consumable by
libraries. In fact, I suspect that will be the case more often than
not. I'm not really sure that I'm following how the proposed API is
library un-friendly?
/ Jonas
Re: Can IndexedDB depend on JavaScript? (WAS: [Bug 9793] New: Allow dates and floating point numbers in keys)
On Sat, May 22, 2010 at 3:58 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, May 21, 2010 at 11:42 PM, bugzi...@jessica.w3.org wrote:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9793
Summary: Allow dates and floating point numbers in keys
Product: WebAppsWG
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Indexed Database API
AssignedTo: nikunj.me...@oracle.com
ReportedBy: pablo.cas...@microsoft.com
QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Currently the spec requires the values referenced by the key path to be
integers or strings. I strongly believe that we should also allow dates
and
floating point numbers (am I missing any other important types?). While
dates
and floating point numbers alone are not good for a primary key, they are
important for non-unique indexes and as part of a composite key, allowing
for
things such as scanning in temporal order.
This is the change I'd like to propose:
Section 3.1.1 Keys of the currently published draft reads:
-
In order to efficiently retrieve records stored in an indexed database, a
user
agent needs to organize each record by its key. Conforming user agents
must
support the use of values of IDL data types [WEBIDL] DOMString and long as
well
as the value null as keys.
For purposes of comparison, a DOMString key is always evaluated higher
than any
long key. Moreover, null always evaluates lower than any DOMString or long
key.
-
New proposed text:
-
In order to efficiently retrieve records stored in an indexed database, a
user
agent needs to organize each record by its key. Conforming user agents
must
support the use of values of IDL data types [WEBIDL] DOMString, long,
float,
and the Date JavaScript object
We really need to decide, once and for all, whether or not IndexedDB is
going to be tied to JavaScript or not. The two major reasons to do so are
the lack of date in WebIDL and keyPath.
KeyPath may be tricky to spec in a way that would work for any language
without cutting out a lot of flexibility. In order to keep what we're
speccing sane, it will probably need to be a pretty small subset of what's
possible in JavaScript and thus even browsers will likely need to roll their
own parser and such to support it. (If we do decide to depend on
JavaScript, it should enable some really neat things with the keyPath as
well.)
The HTML spec defines its own date type, but does not specify sort order at
all. I started a thread on this a bit ago (subject: [IndexedDB/WebIDL]
Dates + Sorting (WAS: Detailed comments for the current draft)) but it only
got one response [3].
Note that a Date type for WebIDL doesn't really affect things a whole
lot for the interfaces in IndexedDB though. The relevant functions all
take 'any' as type though, so we'll still have to describe in prose
what types are permitted. I don't think this makes IndexedDB depend on
javascript though.
What WebIDL would need, and what has been discussed in the past, is
some type of compound types. I.e. that you could specify that an
argument can be a date, an integer, a float or a string.
As for the keyPath issue. The way the spec stands now (where I think
it intends not to allow full expressions), I don't think it really
depends on Javascript. It does depend on the language having some way
to represent structured data. I.e. that the language can hold
something like:
{ foo: bar,
complex: { p1: hello, p2: world} }
I'm not really sure how you would return a value like that to
Objective-C. How does WebKit intend to deal with that in APIs where
this issue already exist, such as postMessage?
/ Jonas
Re: Can IndexedDB depend on JavaScript? (WAS: [Bug 9793] New: Allow dates and floating point numbers in keys)
On Mon, May 24, 2010 at 1:21 PM, Jonas Sicking jo...@sicking.cc wrote:
As for the keyPath issue. The way the spec stands now (where I think
it intends not to allow full expressions), I don't think it really
depends on Javascript. It does depend on the language having some way
to represent structured data. I.e. that the language can hold
something like:
{ foo: bar,
complex: { p1: hello, p2: world} }
I'm not really sure how you would return a value like that to
Objective-C. How does WebKit intend to deal with that in APIs where
this issue already exist, such as postMessage?
Surely any language that has some way of dealing with JSON already has
an answer for this, correct?
~TJ
Re: [IndexedDB] [Bug 9562] New: Opening a database with a different description is underspecified
On 4/20/2010 11:46 AM, bugzi...@jessica.w3.org wrote: The spec is unspecified as to what we should do when a database is opened with a different description than it was previously opened. I'd assume we'd want to update the description. Does anybody else have thoughts on what the right behavior should be here? Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: Do we need to rename the Origin header?
On Mon, 24 May 2010, Bil Corry wrote: Adam Barth wrote on 7/16/2009 10:38 AM: On Thu, Jul 16, 2009 at 8:47 AM, Bil Corryb...@corry.biz wrote: I think you mean everything will NOT be privacy-sensitive except non-XHR GETs. I don't think we've quite settled on exactly what will be privacy sensitive. It's most likely that POSTs and XHR will not be and that hyperlinks and image loads will be. The goal is to harmonize with the Mozilla proposal. I haven't been following the progress of this, has privacy-sensitive been defined in HTML5 yet? Yes. The only reference I could find was in 2.6 Fetching Resources: ---8--- For the purposes of the Origin header, if the fetching algorithm was explicitly initiated from an origin, then the origin that initiated the HTTP request is origin. Otherwise, this is a request from a privacy-sensitive context. [ORIGIN] (from: http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#fetching-resources) ---8--- That is the definition. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [widgets] Zip vs GZip Tar
Hi, Folks- Sorry to jump in on this thread so late; I've been busy and traveling. As W3C Team Contact for this group, I strongly agree with Ian here regarding the tone of some of the responses. Technical comments on this list should be treated with the respect they are due. If you feel something has been adequately covered in the archives, point to an example email. Please keep this list civil, technical, and productive. On a logistical level, I again agree with Ian. I'm rather disappointed that we can't solve this problem more quickly. I think Gregg raised worthwhile use cases and points for consideration [1], and wonder if this might not be dealt with in the Widgets Embedding spec... after all, that is intended for the latter case he mentions. I can think of many worse things than having 2 alternate compression schemes, if the use cases are different. (Yes, I realize I'm speaking loosely and there might be serious technical problems with this approach... I'm just brainstorming here.) Aaron Boodman suggested something [2] on the WHATWG list that sounds suspiciously like Widgets, and it would be a real shame to miss out on this opportunity for increasing the applicability of the Widgets specs in multiple scenarios and platforms. [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0349.html [2] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026488.html Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
