RE: ENISA Smartphone security study
Hi Arthur, All, Apologies - I should have explained a little more what we are looking for from the WG and you are right that some of the questions are out of scope - not answering all the questions is fine. In response to your mail: 1. I thought that some important aspects of Question 1 (the most extensive question) are relevant to the Webapps WG. In particular how the web apps access control mechanisms could be integrated with the device access control mechanisms when used on smartphones (and possibly process authentication and even key management). Are there any security issues in this integration? For example, are there any issues in integrating the CORS spec with the Android permissions model? How would widgets with device API access deal with access to resources which cost money, such as phone calls and those which collect highly sensitive data such as GPS, accelerometer etc...? 2. The questionnaire is just a tool to gather input, which we will use to write up a report. This report and its drafts will be available for review and discussion by the groups who contributed to the questionnaire. We will also clarify responses directly with each contributor. This is what is meant by study. As such the comments are not public, but all drafts will be available to members of the group. I am happy to add the Webapps group to our mailing list if you wish. 3. From the point of view of official position what I meant was that we would like to be able to list the Webapps WG as contributors or consulted in our final report. This is very important to the impact of the final report, which should take into account the views of as many stakeholders as possible (and be seen to do so). This does not mean that we will suggest that you endorse the document in its entirety and we can also negotiate other forms of attribution but our default attribution text would be something like this: List of contributors: This paper was produced by ENISA editors using input and comments from a group selected for their expertise in the subject area, including industry, academic and government experts. The views expressed in this publication are those of the editors, unless stated otherwise, and do not necessarily reflect the opinions of the participating experts. Note that we already have contributions from many of the individual organisations which make up the group, so while it would be nice to have as many responses as possible, we would especially like to have a representation from the Webapps WG. Regards, Giles Hogben Dr Giles Hogben Network Security Policy Expert European Network Information Security Agency (ENISA) -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: 19 May 2010 20:23 To: Giles Hogben Cc: public-webapps Subject: Re: ENISA Smartphone security study Hi Giles, The specifications in scope for the WebApplications WG are platform neutral and device independent. As such, I do not foresee the WG creating an official position on this Smartphone questionnaire since most of the questions are not in scope for WebApps. I presume it would be OK for individuals and/or W3C Member companies to submit comments. Would you please confirm if that is acceptable or not? Also, please send us the Public URL where comments for this study are archived. Regarding the list of questions, I (speaking as an individual) have the following comments: * The following questions are generally out of scope for WebApps: #1, #4, #5, #6, #8, #9, #11. * The Digital Signature for Widgets spec can be viewed as applicable for #2 and #3. * Several of our specs (e.g. CORS, UMP, Widget Interface) include Security Considerations that are relevant for #7 (but specific channels are not in scope). * The proposed Web Notifications will define an alerting mechanism that may be relevant to #10 (e.g. the spec defines generic alerting mechanisms). For a list of WG's specifications in progress, please see the publication status tables at: http://www.w3.org/2008/webapps/wiki/PubStatus -Regards, Art Barstow On 5/19/10 10:27 AM, ext Giles Hogben wrote: Hi, I am a security expert at ENISA (the European Network and Information Security Agency). We conducting a study on smartphone security and would like to have input from the Web Apps WG via the attached questionnaire, as well as reviewing of drafts of the study when it is ready. The questionnaire also explains the goals of the project. Would it be possible to have an official position from the WG? Some other points about the study are: - If necessary, we will hold a number of conference calls to clarify specific issues. - No information which regards sensitive corporate IP will be expected or published. - Contributor names/organisations will be used on the final report only with consent Thanks, Giles Hogben Dr Giles Hogben Network Security Policy
Re: [IndexedDB] KeyPaths and missing properties.
On Thu, May 20, 2010 at 1:24 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 19, 2010 at 4:58 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, May 19, 2010 at 9:38 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 19, 2010 at 2:36 AM, Jeremy Orlow jor...@chromium.org
wrote:
Interesting you'd bring this up. Andrei and I were just looking at
indexes
as specced and wondered whether it still makes sense to allow indexes
to
not
have a keyPath.
I think so. Consider for example a objectStore that contains entries
like:
{ name: Elvis Presley, born: 1935-1-8, death: 1977-8-16 }
But index on how old the person was when he/she died. I guess you
could require that people store a property containing the age, however
it seems unfortunate to require modifying the stored data.
Worse, you might have entries like:
{ id: 5, givenName: Benny, otherNames: [Göran, Bror],
familyName: Andersson, age: 63, interest: Music }
in order to search for people, you might want to search for a name, no
matter if that is a given name, a family name, or second name.
Currently you can accomplish this by inserting 4 entries into an
index, all pointing to the same entry in the objectStore. I can't
think of a sane way to accomplish this using only keyPath.
I think the main use case here is the need to allow an unknown quantity
of
entries in the index to one entry in the objectStore. What if we allowed
keyEntry's to be any javascript expression and allow them to return
arrays
of indexible data. In this case, the expression would return an array of
otherNames + the givenName + the familyName. The keyPath already is
essentially just a javascript expression, so this doesn't seem like too
big
of a leap.
This would also support your age upon death use case. (Though I think
requiring the developer to store that age if they want it indexed isn't
too
bad of an answer either.)
Thoughts?
I think it's an interesting idea, and one that came up when we were
talking to developers way back before IndexedDB spec was started.
However then we more discussed it in the sense that libraries would be
using the technique, rather than that the API would use it.
I agree this is on the borderline between something we should leave to
libraries (for at least v1) and something we should spec now.
The problem with using a javascript expression is how do you provide
it? If you're allowed to pass in a function, that also means that
you're pulling in the full scope of that function. This obviously
doesn't work since the index generally outlives the scope and is used
in other browsing sessions and other tabs.
Sorry, I should have been more clear. I think a string (like what's
currently specced) is definitely the way to go. You're right about the
scoping issues, but what if we ran the expressions without access to the
global scope? In addition to solving this problem (index works when you
first create it, but next time you open the browser it does't) it'd also
keep developers from doing really horrible things...like doing synchronous
XHRs.
So you'd have to pass in the javascript expression as a string. This
certainly works but is more than a little ugly. It also complicates
the implementation a good bit since it now has to include a javascript
engine. Not a huge issue given that all browsers has one anyway, but
feels a bit iffy.
Hm. I'm looking at the spec, and I can't find where (if anywhere) it talks
about what's allowed as a key path. I guess I had assumed that it was
essentially javascript (or maybe some subset) and that we'd at least need to
be parsing it anyway. If we don't adopt this idea because we're worried
about depending on javascript, then we should spec out the keyPath syntax
pretty precisely to ensure we don't have such a dependency.
snip
Oh, interesting! Do you know why the structured clone algorithm is
specced
that way?
Anyway, I'd agree that disallowing it is probably the right answer.
Hmm.. it turns out I'm wrong. It does not in fact drop id property.
Ugh, that complicates serializing arrays quite a bit :(
I still think it's surprising to add properties to arrays, and so I'd
prefer to treat arrays like primitives and other non-plain-objects and
make it an error.
I'm fine with this. I can't think of any use cases it'd get in the way
with.
On Thu, May 20, 2010 at 1:39 AM, Jonas Sicking jo...@sicking.cc wrote:
I still think it's an interesting idea, though I'm not sold on it.
Especially for the first version of the spec.
It seems like there would be a lot of edge cases to define here. First
of all, how is the value passed in to this expression? Do we say that
it's available through some value variable? So that if you want to
index on the foo property, you pass in an expression like
value.foo? Or do we want the value to be the global object, so that
if you wanted to index on the foo property the
Re: [IndexedDB] Proposal for async API changes
Thanks for taking the time to do this! Can you maybe discuss the pros and cons you found in terms of implementing something in WebSQLDatabase vs. IndexedDB? I'm mainly interested in seeing if there's any thing we can improve in IndexedDB that WebSQLDatabase already does well. J On Wed, May 19, 2010 at 10:03 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 5/19/2010 1:50 PM, Shawn Wilsher wrote: Er, and I managed to botch the SQL in the last two examples. Those should be (if my non-tested SQL-fu is right): SELECT name, COUNT(kids.id) FROM kids INNER JOIN candySales ON kids.id = candySales.kidId GROUP BY kids.id; and: SELECT name, COUNT(kids.id) FROM kids LEFT JOIN candySales ON kids.id = candySales.kidId GROUP BY kids.id; respectively. Cheers, Shawn
Re: ENISA Smartphone security study
Giles, On 5/20/10 5:43 AM, ext Giles Hogben wrote: Apologies - I should have explained a little more what we are looking for from the WG and you are right that some of the questions are out of scope - not answering all the questions is fine. In response to your mail: 1. I thought that some important aspects of Question 1 (the most extensive question) are relevant to the Webapps WG. I agree some of those questions are interesting but most are not necessarily in scope for WebApps. I also think the WG's higher priority is to complete the deliverables in the group's charter. That said, if members of the WG or the WebApps community at large (currently about 450 subscribers) have input, they should of course participate in the questionnaire. -Art Barstow
Re: RfC: Three Last Call WDs by the XML Security WG; deadline 11-May-2010
Minor correction, the Last Call period ends 10 June. regards, Frederick Frederick Hirsch, Nokia Chair XML Security WG On May 17, 2010, at 11:03 AM, ext Arthur Barstow wrote: Below is a request to the WebApps WG for comments on 3 LCWDs produced by the XML Security WG: [[ This is a first Last Call for XML Encryption and Generic Hybrid Ciphers specifications. This is a second Last Call for XML Signature 1.1, with the only substantive changes being the result of Last Call feedback, as noted in the status section of that document. ]] The comment deadline is June 11 and comments should be sent to: public-xml...@w3.org http://lists.w3.org/Archives/Public/public-xmlsec/ -Art Barstow Begin forwarded message: From: Hirsch Frederick (Nokia-CIC/Boston) frederick.hir...@nokia.com Date: May 17, 2010 10:48:05 AM EDT To: cha...@w3.org cha...@w3.org Cc: Hirsch Frederick (Nokia-CIC/Boston) frederick.hir...@nokia.com, t...@w3.org t...@w3.org Subject: Transition Announcement: Last Call WD of XML Encryption 1.1, XML Security Generic Hybrid Ciphers and XML Signature 1.1 Archived-At: http://www.w3.org/mid/3DDBC759- e95c-4935-96be-1464cbc4e...@nokia.com 1) This is a Last Call Working Draft transition announcement for three Recommendation track specifications. This is a first Last Call for XML Encryption and Generic Hybrid Ciphers specifications. This is a second Last Call for XML Signature 1.1, with the only substantive changes being the result of Last Call feedback, as noted in the status section of that document. (2) Document title, URIs. 2a) XML Encryption Syntax and Processing Version 1.1 http://www.w3.org/TR/2010/WD-xmlenc-core1-20100513/ 2b) XML Security Generic Hybrid Ciphers http://www.w3.org/TR/2010/WD-xmlsec-generic-hybrid-20100513/ 2c) XML Signature Syntax and Processing Version 1.1 http://www.w3.org/TR/2010/WD-xmldsig-core1-20100513/ (3) Instructions for providing feedback. If you wish to make comments regarding these documents, please send them to public-xml...@w3.org. The list is archived at http:// lists.w3.org/Archives/Public/public-xmlsec/ (4) Review end date. This Last Call period is for four weeks and will end 10 June 2010. (5) A reference to the group's decision to make this transition. The XML Security agreed to making this Last Call transition at its teleconference on 11 May 2010, see http://www.w3.org/2010/05/11- xmlsec-minutes.html#item06 (6) Evidence that the document satisfies group's requirements. Include a link to requirements The XML Security Working Group believe this document satisfies the XML Encryption and XML Signature requirements as outlined in the XML Security 1.1 Requirements and Design Considerations document, see http://www.w3.org/TR/2010/WD-xmlsec-reqs-20100204/ (7) The names of groups with dependencies, explicitly inviting review from them. 7a) Web Applications Working Group (WebApps), http://www.w3.org/ 2008/webapps/ The Web Applications Working Group Digital Signatures for Widgets specification has a dependency on XML Signature 1.1, however the substantive changes in XML Signature 1.1 are for features not used by that specification ( http://www.w3.org/TR/2010/WD-widgets- digsig-20100511/ ). The XML Security Working Group requests review from the Web Applications WG of the XML Signature 1.1 Last Call specification, 7b) Efficient XML Interchange Working Group (EXI), http:// www.w3.org/XML/EXI/ The XML Security WG has made changes to the XML Encryption 1.1 specification to clarify use with EXI formats. The XML Security Working Group requests EXI WG review of XML Encryption 1.1 Last Call specification. (8) Report of any Formal Objections The Working Group has received no formal objections. The Working Group has noted the following in the Status of the Document in XML Signature 1.1 and XML Encryption 1.1: This Last Call Working Draft includes the ECDSAwithSHA256 signature algorithm, which is ECDSA over the P-256 prime curve specified in Section D.2.3 of FIPS 186-3 [FIPS-186-3] (and using the SHA-256 hash algorithm), as a mandatory to implement algorithm. The Working Group may request transition to Candidate Recommendation with this feature marked as at risk. If issues about deployment of this feature are raised during Candidate Recommendation, the group may elect to make this feature optional. (9) A link to a patent disclosure page. http://www.w3.org/2004/01/pp-impl/42458/status The WG is also publishing an update to the XML Security Algorithm Cross-Reference, intended to become a Working Group Note, http:// www.w3.org/TR/2010/WD-xmlsec-algorithms-20100513/ . regards, Frederick Frederick Hirsch, Nokia Chair XML Security WG
RE: [widgets] rename View Mode Media Feature spec
+1 to carelessness. Are we going to have a media feature catalogue in the future? Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Robin Berjon Sent: Wednesday, May 19, 2010 2:42 PM To: Marcos Caceres Cc: public-webapps Subject: Re: [widgets] rename View Mode Media Feature spec On May 18, 2010, at 10:45 , Marcos Caceres wrote: Can we please rename the View Mode Media Feature to The 'view-mode' media feature? The current name of the spec is confusing [me]. Ooh, a naming discussion! I'll be completely honest: I couldn't care less. Since you want it, if no one else objects I'll make the change. -- Robin Berjon - http://berjon.com/ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Kiyoyasu Oishi, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: PFWG comments on View Mode Media Feature
Hi Michael, thanks a lot for your review! On May 19, 2010, at 18:32 , Michael Cooper wrote: The Last Call draft of the View Mode Media Feature states that it Applies to: visual and tactile media types http://www.w3.org/TR/2010/WD-view-mode-20100420/#the--view-mode--media-feature While these view modes make sense for visual media types, they don't seem appropriate for the two tactile media types braille and embossed, as defined in Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. in Section 7.3 Recognized media types http://www.w3.org/TR/CSS2/media.html#media-types Good catch. Listing tactile was unintended, it probably happened by copying over from an existing media query description. This MF indeed makes sense only for visual media. We have removed it from our internal draft. Thanks! -- Robin Berjon - http://berjon.com/
[widgets] Draft minutes from 20 May 2010 voice conf
The draft minutes from the May 20 Widgets voice conference are available at the following and copied below: http://www.w3.org/2010/05/20-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before May 27 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conference 20 May 2010 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2010AprJun/0763.html See also: [3]IRC log [3] http://www.w3.org/2010/05/20-wam-irc Attendees Present Art, Robin, StevenP, Josh, Kenneth, Marcos Regrets Chair Art Scribe Art Contents * [4]Topics 1. [5]Agenda review 2. [6]Announcements 3. [7]Packaging and Configuration spec 4. [8]Widget Interface spec 5. [9]Access Requests Policy (WARP) spec 6. [10]URI Scheme spec 7. [11]View Modes Media Features spec: 8. [12]AOB * [13]Summary of Action Items _ scribe ScribeNick: ArtB scribe Scribe: Art Date: 20 May 2010 Agenda review AB: draft agenda was posted on May 19 ( [14]http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/07 63.html ). Any change requests? ... we will add PF WG's comment about VMMF LC [14] http://lists.w3.org/Archives/Public/public-webapps/ 2010AprJun/0763.html Announcements AB: deadline for comments re Digital Signatures for Widgets LCWD is June 1 Packaging and Configuration spec AB: on April 6 I asked the I18N WG to respond to the span and dir changes. On May 12 I asked them again ( [15]http://lists.w3.org/Archives/Public/www-archive/2010May/0002.htm l ). I haven't received any response. ... do you Steven know I18N WG's status on this? [15] http://lists.w3.org/Archives/Public/www-archive/2010May/ 0002.html SP: no, but I'll find out AB: let's not block on this now and move to next topic Widget Interface spec AB: we have one issue that is blocking moving the spec to PR ... ISSUE-116 Need to flesh out the security considerations for the openURL method in the Widget Interface spec ( [16]http://www.w3.org/2008/webapps/track/issues/116 ) ... Marcos has already added some text [16] http://www.w3.org/2008/webapps/track/issues/116 Steven i18n discussed it yesterday; Addison is actioned to reply, and will do so soon RB: think he is awaiting some response AB: thanks SP ... yes, there was some offlist discussion but I forwarded that discussion to public-webapps ... here is the thread I mentioned [17]http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/05 70.html ... how do we make progress on this issue? [17] http://lists.w3.org/Archives/Public/public-webapps/ 2010AprJun/0570.html RB: the changes must be satisfactory to the comments ... then we can move to PR scribe ACTION: marcos to follow-up with TLR and Adam Barth re ISSUE-116 [recorded in [18]http://www.w3.org/2010/05/20-wam-minutes.html#action01] trackbot Created ACTION-550 - Follow-up with TLR and Adam Barth re ISSUE-116 [on Marcos Caceres - due 2010-05-27]. RB: do we need to move PC fwd first? AB: no, I don't think so Access Requests Policy (WARP) spec AB: there was a thread about Assertion ta-?? ( [19]http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/05 69.html ) between Scott Wilson and Marcos [19] http://lists.w3.org/Archives/Public/public-webapps/ 2010AprJun/0569.html MC: I made it clear what needs to be done ... I expect Scott to make the change AB: ACTION-539 - what WARP should or should not say for the default security model ( [20]http://www.w3.org/2008/webapps/track/actions/539 ) [20] http://www.w3.org/2008/webapps/track/actions/539 RB: I responded to the thread ... if people aren't happy with it, we can change it MC: I don't think the model is clear enough RB: the model is to deny everything MC: if the WARP model applies, do not have a http origin RB: but the target is local widget MC: I agree that has always been the model ... but that needs to be more clear RB: so you want to say the model does not apply to non http origins MC: yes ACTION-539? trackbot ACTION-539 -- Robin Berjon to work with Marcos on what WARP should or should not say for the default security model re AB: is some additional text needed re the default policy ( [21]http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/04 56.html ) -- due 2010-05-13 -- OPEN [21] http://lists.w3.org/Archives/Public/public-webapps/ 2010AprJun/0456.html trackbot
Re: [IndexedDB] Proposal for async API changes
On 5/20/2010 2:55 AM, Jeremy Orlow wrote: Thanks for taking the time to do this! Can you maybe discuss the pros and cons you found in terms of implementing something in WebSQLDatabase vs. IndexedDB? I'm mainly interested in seeing if there's any thing we can improve in IndexedDB that WebSQLDatabase already does well. So far it's really just that joins are painful in IndexedDB. I'm working on a blog post on this very topic though, and I'll be sure to point everyone in this thread to it (I figure this is useful stuff to get out to a wider audience). Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] KeyPaths and missing properties.
Hi,
On Thu, May 20, 2010 at 10:47 AM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, May 20, 2010 at 1:24 AM, Jonas Sicking jo...@sicking.cc wrote:
It seems like there would be a lot of edge cases to define here. First
of all, how is the value passed in to this expression? Do we say that
it's available through some value variable? So that if you want to
index on the foo property, you pass in an expression like
value.foo? Or do we want the value to be the global object, so that
if you wanted to index on the foo property the expression would
simply be foo?
Since we're already talking about requiring that data being inserted into
objectStores with a keyPath (for its primary key or in one of its indexes),
setting it as the global object seems reasonable. And it matches what's
currently specced for the simple 1 entityStore entry to 1 index entry (per
index) case.
Also, what happens if the javascript expression modifies the value?
Does the implementation have to clone the value before calling each
index expression?
In order of how much I like the idea:
1) In an ideal world, we'd spec it to be read only, but I'm not sure if most
JS engines have an easy way to do something like that.
2) Another possibility is to make the order in which indexes are processed
deterministic. That way, if someone does modify it, it'll at least
be consistent.
3) Cloning is another possibility, but it seems like it'd have a performance
impact. Maybe optimized implementations could copy-on-write it, though?
While it's true that allowing the keyPath to be any javascript
expression would be very elegant and flexible (although probably quite
difficult to explain in the spec), maybe it's worth considering a
simpler solution? For instance, could the keyPath be simply an array
of strings, with each string denoting the name of a property of the
objects in the store. So in Jonas' example:
{ id: 5, givenName: Benny, otherNames: [Göran, Bror],
familyName: Andersson, age: 63, interest: Music }
The keyPath could be set to
[givenName, otherNames, familyName].
The indexable data for this record would therefore be {Benny,
Göran, Bror, Andersson}.
Thanks,
Andrei
Re: [IndexedDB] KeyPaths and missing properties.
On Thu, May 20, 2010 at 3:55 PM, Andrei Popescu andr...@google.com wrote:
Hi,
On Thu, May 20, 2010 at 10:47 AM, Jeremy Orlow jor...@chromium.org
wrote:
On Thu, May 20, 2010 at 1:24 AM, Jonas Sicking jo...@sicking.cc wrote:
It seems like there would be a lot of edge cases to define here. First
of all, how is the value passed in to this expression? Do we say that
it's available through some value variable? So that if you want to
index on the foo property, you pass in an expression like
value.foo? Or do we want the value to be the global object, so that
if you wanted to index on the foo property the expression would
simply be foo?
Since we're already talking about requiring that data being inserted into
objectStores with a keyPath (for its primary key or in one of its
indexes),
setting it as the global object seems reasonable. And it matches what's
currently specced for the simple 1 entityStore entry to 1 index entry
(per
index) case.
Also, what happens if the javascript expression modifies the value?
Does the implementation have to clone the value before calling each
index expression?
In order of how much I like the idea:
1) In an ideal world, we'd spec it to be read only, but I'm not sure if
most
JS engines have an easy way to do something like that.
2) Another possibility is to make the order in which indexes are
processed
deterministic. That way, if someone does modify it, it'll at least
be consistent.
3) Cloning is another possibility, but it seems like it'd have a
performance
impact. Maybe optimized implementations could copy-on-write it, though?
While it's true that allowing the keyPath to be any javascript
expression would be very elegant and flexible (although probably quite
difficult to explain in the spec), maybe it's worth considering a
simpler solution? For instance, could the keyPath be simply an array
of strings, with each string denoting the name of a property of the
objects in the store. So in Jonas' example:
{ id: 5, givenName: Benny, otherNames: [Göran, Bror],
familyName: Andersson, age: 63, interest: Music }
The keyPath could be set to
[givenName, otherNames, familyName].
The indexable data for this record would therefore be {Benny,
Göran, Bror, Andersson}.
If we're OK making the script depend on JavaScript, I still like my
suggestion a bit better. But assuming we're not, I think this would be a
fine way to solve the problem.
Btw, if we're not depending on JavaScript, then whether or not we change any
of this, we'll need to essentially spec our own language for the keyPath.
(As far as I can tell, there's no normative language for the parsing of
keyPath strings in the current spec. And if we're trying not to depend on
JavaScript, we'll basically have to explain the parsing and how it maps to
objects in a completely language independent fashion.)
J
Re: [IndexedDB] KeyPaths and missing properties.
On Thu, May 20, 2010 at 7:55 AM, Andrei Popescu andr...@google.com wrote:
Hi,
On Thu, May 20, 2010 at 10:47 AM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, May 20, 2010 at 1:24 AM, Jonas Sicking jo...@sicking.cc wrote:
It seems like there would be a lot of edge cases to define here. First
of all, how is the value passed in to this expression? Do we say that
it's available through some value variable? So that if you want to
index on the foo property, you pass in an expression like
value.foo? Or do we want the value to be the global object, so that
if you wanted to index on the foo property the expression would
simply be foo?
Since we're already talking about requiring that data being inserted into
objectStores with a keyPath (for its primary key or in one of its indexes),
setting it as the global object seems reasonable. And it matches what's
currently specced for the simple 1 entityStore entry to 1 index entry (per
index) case.
Also, what happens if the javascript expression modifies the value?
Does the implementation have to clone the value before calling each
index expression?
In order of how much I like the idea:
1) In an ideal world, we'd spec it to be read only, but I'm not sure if most
JS engines have an easy way to do something like that.
2) Another possibility is to make the order in which indexes are processed
deterministic. That way, if someone does modify it, it'll at least
be consistent.
3) Cloning is another possibility, but it seems like it'd have a performance
impact. Maybe optimized implementations could copy-on-write it, though?
While it's true that allowing the keyPath to be any javascript
expression would be very elegant and flexible (although probably quite
difficult to explain in the spec), maybe it's worth considering a
simpler solution? For instance, could the keyPath be simply an array
of strings, with each string denoting the name of a property of the
objects in the store. So in Jonas' example:
{ id: 5, givenName: Benny, otherNames: [Göran, Bror],
familyName: Andersson, age: 63, interest: Music }
The keyPath could be set to
[givenName, otherNames, familyName].
The indexable data for this record would therefore be {Benny,
Göran, Bror, Andersson}.
This wouldn't solve the case when the key is the result of a
calculation, such as my age-at-time-of-death example. Consider also
wanting to store objects like
{ id: 5, name: Benny Andersson, address: 1 Ohai Street\n Wahiawa, HI 96786 }
but wanting to index on the first name or on the state in the address.
/ Jonas
Re: [IndexedDB] Proposal for async API changes
On Thu, May 20, 2010 at 7:34 AM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 5/20/2010 2:55 AM, Jeremy Orlow wrote:
Thanks for taking the time to do this!
Can you maybe discuss the pros and cons you found in terms of implementing
something in WebSQLDatabase vs. IndexedDB? I'm mainly interested in
seeing
if there's any thing we can improve in IndexedDB that WebSQLDatabase
already
does well.
So far it's really just that joins are painful in IndexedDB. I'm working on
a blog post on this very topic though, and I'll be sure to point everyone in
this thread to it (I figure this is useful stuff to get out to a wider
audience).
For what it's worth, one of the ideas behind object stores, rather
than rows+column stores, is to reduce the need for joins. I.e. in our
candy store example you could just as well store objects like:
{ id: 1, name: Adam, sales: [{candyId: 1, date: 2010-01-02}, ...]}
However we wanted to use joins in our examples as they are a good way
to illustrate more complex queries and are sure to still happen, even
if less often.
/ Jonas
Re: [IndexedDB] Proposal for async API changes
On 5/20/2010 9:03 AM, Jonas Sicking wrote:
For what it's worth, one of the ideas behind object stores, rather
than rows+column stores, is to reduce the need for joins. I.e. in our
candy store example you could just as well store objects like:
{ id: 1, name: Adam, sales: [{candyId: 1, date: 2010-01-02}, ...]}
Well, if people care about the size of data on disk, they will likely
want to normalize their object stores. We had talked about doing joins
before in indexedDB, but I believe we decided to punt on the issue for now.
Cheers,
Shawn
smime.p7s
Description: S/MIME Cryptographic Signature
[widgets PC] i18n comment 17 : What ITS did
Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 17 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: RI Location in reviewed document: Changes since last pubn [http://dev.w3.org/2006/waf/widgets/] Comment: I propose: which is what ITS did = which is how ITS tags were formerly specified here The ITS specification doesn't require use of a namespace, and it would be good to change this wording so that that idea is not incorrectly reinforced. Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
[widgets PC] i18n comment 18 : Empty dir value
Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 18 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: RI Location in reviewed document: 7.5.3 [http://dev.w3.org/2006/waf/widgets/#examples-of-usage] Comment: The last example shows an empty value for the dir attribute which is not specified elsewhere. I believe this example is a hark-back to an earlier draft that wasn't removed when we decided to remove dir=. Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
[widgets PC] i18n comment 19 : Corrupted Chinese text
Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 19 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: RI Location in reviewed document: 7.12.4 [http://dev.w3.org/2006/waf/widgets/#example-of-usage5] Comment: The Chinese characters in name xml:lang=zh-cn?/name have become corrupted. Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
[widgets PC] i18n comment 20 : Misuse of xml:lang for localization flag
Comment from the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 20 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: S Tracked by: RI Location in reviewed document: 7.16.1 [http://dev.w3.org/2006/waf/widgets/#example-of-usage9] Comment: Note: I am marking this as closed straight away, since I believe it was not spotted early enough to be corrected. I am recording it here, however, in case it is useful for a future discussion. xml:lang should really only be used to indicate the language of content in an element. If you need to indicate something else, such as the locale for that content for localization purposes, you should use a different attribute. See a href=http://www.w3.org/International/questions/qa-when-xmllang;xml:lang in XML document schemas/a. Here not only is xml:lang used incorrectly for that reason, but xml:lang= is defined to mean that this is the default locale, whereas the XML spec says that that should mean that the language of the content of that element is undetermined (see Tagging text with no language [http://www.w3.org/International/questions/qa-no-language]). It would have been better to use an attribute such as locale='en', locale='fr', or locale=''. This would be used alongside xml:lang. The former would indicate how to process the document, the latter would be useful for things like spell-checking, voice browsers, etc that need to understand the language of the text they are processing. This would simplify the code in the example in section 7.16.1. Instead of: name xml:lang= dir=ltrspan xml:lang=enGPS Weather!/span/name you could simply use name locale= xml:lang=en dir=ltrGPS Weather!/name Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
[widgets PC] i18n comment 15 : Persian dir examples
*Further comments* related to the i18n review of: http://dev.w3.org/2006/waf/widgets/ Comment 15 At http://www.w3.org/International/reviews/0907-widgets-pc/ Editorial/substantive: E Tracked by: RI Location in reviewed document: 7.5.3. Examples of Usage [http://dev.w3.org/2006/waf/widgets/#examples-of-usage] Comment: The first example displays incorrectly (eg. the angle bracket points the wrong way and is in the wrong place). Replace the appropriate bit of code with the following and this should look ok: lt;name short=آب و هواgt;#x200E; آب و هوا برنامهlt;/namegt; The third example seems to have rather strange ordering in the Persian text and English, and the English word seems like an odd one to have in English. How about the following? lt;widget xmlns=http://www.w3.org/ns/widgetsgt; lt;name short=Weathergt; Weather! a totally awesome application! lt;/namegt; lt;name short=آب و هوا xml:lang=fa dir=rtlgt; lt;span dir=ltr xml:lang=engt;Weather!lt;/spangt; برنامه واقعا بزرگ lt;/namegt; lt;/widgetgt; Hope that helps, RI Richard Ishida Internationalization Lead W3C (World Wide Web Consortium) http://www.w3.org/International/ http://rishida.net/
Re: [IndexDB] Proposal for async API changes
Hi Jonas, A draft of the proposed API is here: http://docs.google.com/View?id=dfs2skx2_4g3s5f857 As someone new to this API, I thought the naming used in the current draft is somewhat confusing. Consider the following interfaces: IndexedDatabase IndexedDatabaseRequest, IDBDatabaseRequest, IDBDatabase, IDBRequest Just by looking at this, it is pretty hard to understand what the relationship between these interfaces really is and what role do they play in the API. For instance, I thought that the IDBDatabaseRequest is some type of Request when, in fact, it isn't a Request at all. It also isn't immediately obvious what the difference between IndexedDatabase and IDBDatabase really is, etc. I really don't want to start a color of the bikeshed argument and I fully understand how you reached the current naming convention. However, I thought I'd suggest a three small changes that could help other people understand this API easier: - I know we need to keep the IDB prefix in order to avoid collisions with other APIs. I would therefore think we should keep the IDB prefix and make sure all the interfaces start with it (right now they don't). - The Request suffix is now used to denote the asynchronous versions of the API interfaces. These interfaces aren't actually Requests of any kind, so I would like to suggest changing this suffix. In fact, if the primary usage of this API is via its async version, we could even drop this suffix altogether and just add Sync to the synchronous versions? - Some of the interfaces could have names that would more closely reflect their roles in the API. For instance, IDBDatabase could be renamed to IDBConnection, since in the spec it is described as a connection to the database. Likewise, IndexedDatabase could become IDBFactory since it is used to create database connections or key ranges. In any case, I want to make it clear that the current naming works once one takes the time to understand it. On the other hand, if we make it easier for people to understand the API, we could hopefully get feedback from more developers. Thanks, Andrei
Re: [IndexedDB] Proposal for async API changes
On 5/20/2010 11:30 AM, Andrei Popescu wrote: As someone new to this API, I thought the naming used in the current draft is somewhat confusing. Consider the following interfaces: IndexedDatabase IndexedDatabaseRequest, IDBDatabaseRequest, IDBDatabase, IDBRequest Just by looking at this, it is pretty hard to understand what the relationship between these interfaces really is and what role do they play in the API. For instance, I thought that the IDBDatabaseRequest is some type of Request when, in fact, it isn't a Request at all. It also isn't immediately obvious what the difference between IndexedDatabase and IDBDatabase really is, etc. It should be noted that we did not want to rock the boat too much with our proposal, so we stuck with the existing names. I think the current spec as written has the same issues. - I know we need to keep the IDB prefix in order to avoid collisions with other APIs. I would therefore think we should keep the IDB prefix and make sure all the interfaces start with it (right now they don't). I agree with this. We should probably file a bug about this. - The Request suffix is now used to denote the asynchronous versions of the API interfaces. These interfaces aren't actually Requests of any kind, so I would like to suggest changing this suffix. In fact, if the primary usage of this API is via its async version, we could even drop this suffix altogether and just add Sync to the synchronous versions? I agree that Request seems confusing and seems to be contrary to what other specs use. We should try to follow what other specs do here. - Some of the interfaces could have names that would more closely reflect their roles in the API. For instance, IDBDatabase could be renamed to IDBConnection, since in the spec it is described as a connection to the database. Likewise, IndexedDatabase could become IDBFactory since it is used to create database connections or key ranges. This sounds good as well. In any case, I want to make it clear that the current naming works once one takes the time to understand it. On the other hand, if we make it easier for people to understand the API, we could hopefully get feedback from more developers. Making it easier for someone to look at the method names and just know how to use the API seems like a good goal in my book. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] Proposal for async API changes
On Thu, May 20, 2010 at 11:55 AM, Shawn Wilsher sdwi...@mozilla.com wrote: On 5/20/2010 11:30 AM, Andrei Popescu wrote: As someone new to this API, I thought the naming used in the current draft is somewhat confusing. Consider the following interfaces: IndexedDatabase IndexedDatabaseRequest, IDBDatabaseRequest, IDBDatabase, IDBRequest Just by looking at this, it is pretty hard to understand what the relationship between these interfaces really is and what role do they play in the API. For instance, I thought that the IDBDatabaseRequest is some type of Request when, in fact, it isn't a Request at all. It also isn't immediately obvious what the difference between IndexedDatabase and IDBDatabase really is, etc. It should be noted that we did not want to rock the boat too much with our proposal, so we stuck with the existing names. I think the current spec as written has the same issues. We kept the existing names specifically to avoid tying bikeshed naming discussions to technical discussion about how these interfaces should behave :) - I know we need to keep the IDB prefix in order to avoid collisions with other APIs. I would therefore think we should keep the IDB prefix and make sure all the interfaces start with it (right now they don't). I agree with this. We should probably file a bug about this. - The Request suffix is now used to denote the asynchronous versions of the API interfaces. These interfaces aren't actually Requests of any kind, so I would like to suggest changing this suffix. In fact, if the primary usage of this API is via its async version, we could even drop this suffix altogether and just add Sync to the synchronous versions? I agree that Request seems confusing and seems to be contrary to what other specs use. We should try to follow what other specs do here. Agreed on both accounts. There unfortunately isn't much in the way of precedence here. There are three other specs to look at here, which specify API for both workers and main thread. * Web Workers spec http://www.whatwg.org/specs/web-workers/current-work/ This spec doesn't actually use different interfaces for workers and main thread. * File API http://dev.w3.org/2006/webapi/FileAPI/ Specifies FileReader and FileReaderSync. The two interfaces are separate and doesn't inherit from a common base * WebSQLDatabase http://dev.w3.org/html5/webdatabase/ Specifies separate interfaces, like Database and DatabaseSync. The two interfaces are separate and doesn't inherit from a common base. I think we should follow the same convention as File API and WebSQLDatabase. There really isn't anything to be gained by having a common base interface, it just makes the spec harder to read as functionality is distributed between the base interface and the sync/async interface. I additionally like the naming convention. The async interfaces is probably the interface that people will use first. Additionally that interface is available both to workers and to the main thread. So it makes sense to give the async interface the simpler name. - Some of the interfaces could have names that would more closely reflect their roles in the API. For instance, IDBDatabase could be renamed to IDBConnection, since in the spec it is described as a connection to the database. Not really sold on this. I've always hated the connection abstraction. With our suggested API IDBDatabase really just holds metadata information about the database, and doesn't need to represent a connection at all. Likewise, IndexedDatabase could become IDBFactory since it is used to create database connections or key ranges. This I agree with though. In any case, I want to make it clear that the current naming works once one takes the time to understand it. On the other hand, if we make it easier for people to understand the API, we could hopefully get feedback from more developers. Making it easier for someone to look at the method names and just know how to use the API seems like a good goal in my book. Agreed. The 'Request' suffix in particular took me quite a while to get used to. / Jonas
Re: [IndexedDB] Proposal for async API changes
On Thu, May 20, 2010 at 8:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, May 20, 2010 at 11:55 AM, Shawn Wilsher sdwi...@mozilla.com wrote: On 5/20/2010 11:30 AM, Andrei Popescu wrote: As someone new to this API, I thought the naming used in the current draft is somewhat confusing. Consider the following interfaces: IndexedDatabase IndexedDatabaseRequest, IDBDatabaseRequest, IDBDatabase, IDBRequest Just by looking at this, it is pretty hard to understand what the relationship between these interfaces really is and what role do they play in the API. For instance, I thought that the IDBDatabaseRequest is some type of Request when, in fact, it isn't a Request at all. It also isn't immediately obvious what the difference between IndexedDatabase and IDBDatabase really is, etc. It should be noted that we did not want to rock the boat too much with our proposal, so we stuck with the existing names. I think the current spec as written has the same issues. We kept the existing names specifically to avoid tying bikeshed naming discussions to technical discussion about how these interfaces should behave :) Totally agree with both of you! But I think now is as good of a time as any to discuss these issues (since they apply to both specs). In this case, I actually don't think this is really bike shedding since we're all agreeing the current names are confusing, but I guess the line is fine. :-) - I know we need to keep the IDB prefix in order to avoid collisions with other APIs. I would therefore think we should keep the IDB prefix and make sure all the interfaces start with it (right now they don't). I agree with this. We should probably file a bug about this. - The Request suffix is now used to denote the asynchronous versions of the API interfaces. These interfaces aren't actually Requests of any kind, so I would like to suggest changing this suffix. In fact, if the primary usage of this API is via its async version, we could even drop this suffix altogether and just add Sync to the synchronous versions? I agree that Request seems confusing and seems to be contrary to what other specs use. We should try to follow what other specs do here. Agreed on both accounts. There unfortunately isn't much in the way of precedence here. There are three other specs to look at here, which specify API for both workers and main thread. * Web Workers spec http://www.whatwg.org/specs/web-workers/current-work/ This spec doesn't actually use different interfaces for workers and main thread. * File API http://dev.w3.org/2006/webapi/FileAPI/ Specifies FileReader and FileReaderSync. The two interfaces are separate and doesn't inherit from a common base * WebSQLDatabase http://dev.w3.org/html5/webdatabase/ Specifies separate interfaces, like Database and DatabaseSync. The two interfaces are separate and doesn't inherit from a common base. I think we should follow the same convention as File API and WebSQLDatabase. There really isn't anything to be gained by having a common base interface, it just makes the spec harder to read as functionality is distributed between the base interface and the sync/async interface. I additionally like the naming convention. The async interfaces is probably the interface that people will use first. Additionally that interface is available both to workers and to the main thread. So it makes sense to give the async interface the simpler name. Agreed on all counts. I would add that, if we did decide to keep base interfaces, we could always suffix them with Base (which I think makes it more clear they're base interfaces)...but it sounds like that might not be necessary. - Some of the interfaces could have names that would more closely reflect their roles in the API. For instance, IDBDatabase could be renamed to IDBConnection, since in the spec it is described as a connection to the database. Not really sold on this. I've always hated the connection abstraction. With our suggested API IDBDatabase really just holds metadata information about the database, and doesn't need to represent a connection at all. Well, if we don't make these proposed changes, then I think it's pretty important to rename to connection since the current spec does distinguish between each connection. With your proposal, this is not currently true, but I think it's hard to say whether or not these concepts will creep back in in later versions. In addition, the entire spec is related to databases, so I think naming it a connection rather than a database helps distinguish it from the rest. That said, if IndexedDatabase* becomes IDBFactory* then there certainly is a lot less confusion already, and this change is less important. J
Re: [IndexedDB] Proposal for async API changes
On 5/20/2010 12:19 PM, Jonas Sicking wrote: I additionally like the naming convention. The async interfaces is probably the interface that people will use first. Additionally that interface is available both to workers and to the main thread. So it makes sense to give the async interface the simpler name. That is not how it is currently specified (and our proposal doesn't indicate either way). The asynchronous versions are not available to worker threads. I do recall discussion on this, however... Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] Proposal for async API changes
On Thu, May 20, 2010 at 9:37 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 5/20/2010 12:19 PM, Jonas Sicking wrote: I additionally like the naming convention. The async interfaces is probably the interface that people will use first. Additionally that interface is available both to workers and to the main thread. So it makes sense to give the async interface the simpler name. That is not how it is currently specified (and our proposal doesn't indicate either way). The asynchronous versions are not available to worker threads. I do recall discussion on this, however... There was discussion, and I'm pretty sure the consensus was that it should be added. The main reason is that we want code that works in the page to work in a worker and that it really isn't much of a burden to implementors. I'll open an issue on this (tomorrow). J
Re: Updates to File API
Jonas Sicking wrote: On Wed, May 19, 2010 at 1:09 PM, Arun Ranganathan a...@mozilla.com wrote: 3. The renaming of the property to 'url' also suggests that we should cease to consider an urn:uuid scheme. I'm not sure that one follows from the other. The property's called 'url' because that's what will be familiar to authors, but the magic string that goes inside of it could still be a URN. FWIW, I'm a developer and sticking a URN in a .url property really doesn't seem familiar at all - even a '.id' property with an id that was consistently generated would be much better. If the scope of the identifiers is limited to a single ua, on a single machine, and specific to that single ua (as in I can't expect to request the identifier outside of the ua that provided it on x machine and get the same results) then I (personally) can't see why there's a need for anything more than a simple unique identifier (sha1 or suchlike) And if the above is true, then surely this would negate the need for .url, registering a new URI scheme, or URN namespace - and all in save you all from lots of headaches time wasted, close the issue, and save the developer community from years of further confusion (or should i say conflated understanding of what a URL is), and benefit the entire web by saving us from yet another (predominantly unneeded) URN namespace or URL scheme. Best leave this in your capable hands. Nathan
Re: [IndexedDB] Proposal for async API changes
On 5/20/2010 7:34 AM, Shawn Wilsher wrote: So far it's really just that joins are painful in IndexedDB. I'm working on a blog post on this very topic though, and I'll be sure to point everyone in this thread to it (I figure this is useful stuff to get out to a wider audience). And honestly, I thought that we had discussed joins on this list, but I only see a thread from Pablo mentioning it, but no real discussions. Should we start that? Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] Proposal for async API changes
On Thu, May 20, 2010 at 11:25 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 5/20/2010 7:34 AM, Shawn Wilsher wrote: So far it's really just that joins are painful in IndexedDB. I'm working on a blog post on this very topic though, and I'll be sure to point everyone in this thread to it (I figure this is useful stuff to get out to a wider audience). And honestly, I thought that we had discussed joins on this list, but I only see a thread from Pablo mentioning it, but no real discussions. Should we start that? Joins were actually in the original spec but taken out during the effort to simply the API greatly. IIRC, the main reason why Nikunj took them out is that we believed you could fairly efficiently join yourself if you had 2 sorted lists and because we didn't see a simple way to do them without introducing a lot of API surface area or creating (or borrowing) some sort of syntax for the joins. (Now that I think about it, though, maybe doing this is not that big of a leap from what we're going to need to do to spec keyPaths. I'm starting to wonder if we need to rethink that as well) Anyway, the decision was made so long ago that maybe it's worth re-opening the discussion. I'll hunt through my mail archives tomorrow and start a new thread with references to any original bits of info I can find. J
Re: Updates to File API
On Thu, May 20, 2010 at 2:53 PM, Nathan nat...@webr3.org wrote:
Jonas Sicking wrote:
On Wed, May 19, 2010 at 1:09 PM, Arun Ranganathan a...@mozilla.com
wrote:
3. The renaming of the property to 'url' also suggests that we should
cease to consider an urn:uuid scheme.
I'm not sure that one follows from the other. The property's called
'url'
because that's what will be familiar to authors, but the magic string
that
goes inside of it could still be a URN.
FWIW, I'm a developer and sticking a URN in a .url property really doesn't
seem familiar at all - even a '.id' property with an id that was
consistently generated would be much better.
If the scope of the identifiers is limited to a single ua, on a single
machine, and specific to that single ua (as in I can't expect to request the
identifier outside of the ua that provided it on x machine and get the same
results) then I (personally) can't see why there's a need for anything more
than a simple unique identifier (sha1 or suchlike)
And if the above is true, then surely this would negate the need for .url,
registering a new URI scheme, or URN namespace - and all in save you all
from lots of headaches time wasted, close the issue, and save the
developer community from years of further confusion (or should i say
conflated understanding of what a URL is), and benefit the entire web by
saving us from yet another (predominantly unneeded) URN namespace or URL
scheme.
Note that the important point of these URNs isn't that they are
identifiers, but rather that you can point a iframe.src, or a
img.src, or a #myElement { background-url: url(...) } at them. In
all useful use cases brought up so far, the website author will never
look at the actual string to see what it contains, but rather just
treat it as a url and load data from it.
The intended use for it is things like:
img id=preview
input type=file onchange=document.getElementById('preview').src =
this.files[0].url
In this context, calling the string an identifier misses the point IMHO.
(btw, the above example should work fine in nightly firefox builds)
/ Jonas
RE: [IndexedDB] Proposal for async API changes
(still catching up on the rest of the long thread of API changes, will get back to that a bit later) From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Thursday, May 20, 2010 3:34 PM On Thu, May 20, 2010 at 11:25 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 5/20/2010 7:34 AM, Shawn Wilsher wrote: So far it's really just that joins are painful in IndexedDB. I'm working on a blog post on this very topic though, and I'll be sure to point everyone in this thread to it (I figure this is useful stuff to get out to a wider audience). And honestly, I thought that we had discussed joins on this list, but I only see a thread from Pablo mentioning it, but no real discussions. Should we start that? Joins were actually in the original spec but taken out during the effort to simply the API greatly. IIRC, the main reason why Nikunj took them out is that we believed you could fairly efficiently join yourself if you had 2 sorted lists and because we didn't see a simple way to do them without introducing a lot of API surface area or creating (or borrowing) some sort of syntax for the joins. (Now that I think about it, though, maybe doing this is not that big of a leap from what we're going to need to do to spec keyPaths. I'm starting to wonder if we need to rethink that as well) Anyway, the decision was made so long ago that maybe it's worth re-opening the discussion. I'll hunt through my mail archives tomorrow and start a new thread with references to any original bits of info I can find. My main concern with joins, besides API surface, was that in order to implement joins you need to choose an actual strategy. Depending on whether you have indexes or not and other circumstances you could choose to do range scans/lookups, a merge join, etc. So at least for fancier libraries this would only be of partial help, as they would probably want to do their own joins sometimes. I'm happy to explore again though. It's certainly the case that for simpler cases it might help users pull off tasks without depending on a library. I do wonder if we should try and land the async API first. -pablo J
Re: [IndexedDB] KeyPaths and missing properties.
So you'd have to pass in the javascript expression as a string. This certainly works but is more than a little ugly. It also complicates the implementation a good bit since it now has to include a javascript engine. Not a huge issue given that all browsers has one anyway, but feels a bit iffy. Hm. I'm looking at the spec, and I can't find where (if anywhere) it talks about what's allowed as a key path. I guess I had assumed that it was essentially javascript (or maybe some subset) and that we'd at least need to be parsing it anyway. If we don't adopt this idea because we're worried about depending on javascript, then we should spec out the keyPath syntax pretty precisely to ensure we don't have such a dependency. snip I think the intent of the current syntax is that it's a '.' separated list of property names. But yes, it definitely needs to be precisely defined. I still think it's an interesting idea, though I'm not sold on it. Especially for the first version of the spec. It seems like there would be a lot of edge cases to define here. First of all, how is the value passed in to this expression? Do we say that it's available through some value variable? So that if you want to index on the foo property, you pass in an expression like value.foo? Or do we want the value to be the global object, so that if you wanted to index on the foo property the expression would simply be foo? Since we're already talking about requiring that data being inserted into objectStores with a keyPath (for its primary key or in one of its indexes), setting it as the global object seems reasonable. And it matches what's currently specced for the simple 1 entityStore entry to 1 index entry (per index) case. You also have to specify how the value is returned. I.e. does the expression need to end with 'return X'? Or do we index on the result of the value returned from the last executed expression? Also, I think that if the value is the global object, then I declaring variables inside the expression modifies the value as global variables are set on the global object. Also, what happens if the javascript expression modifies the value? Does the implementation have to clone the value before calling each index expression? In order of how much I like the idea: 1) In an ideal world, we'd spec it to be read only, but I'm not sure if most JS engines have an easy way to do something like that. 2) Another possibility is to make the order in which indexes are processed deterministic. That way, if someone does modify it, it'll at least be consistent. 3) Cloning is another possibility, but it seems like it'd have a performance impact. Maybe optimized implementations could copy-on-write it, though? I think 1 and 3 suffers from the same problem of not being something that JS engines usually need to do, and so likely isn't implemented. In both cases you have to be able to mark an object graph such that you take special action if it's modified. And for 2, do you do the structured clone before or after you run the keyPath expressions? Not until after you've created the structured clone will you know if the value can even be stored. In short, I'd like to see a comprehensive proposal :) Then I could take that to the JS team and ask if it's implementable. / Jonas
