Re: Do we need to rename the Origin header?
On Thu, 9 Apr 2009, Bil Corry wrote: For example, imagine instead you visit a malicious site, and it wants to phish your banking credentials. But rather than choosing a random bank and hoping you bank there, it instead launches a series of timing attacks against the top 30 banks, determines which bank(s) you're logged into, then tries phishing against the one you're logged into. CORS-Origin can't help, but a robust Origin could. You could just do a timing attack against non-login-protected assets that are only shown while logged in, or even just do timing attacks against any cached resource from the site, to see if they visited it. Or heck, you could just do a regular :visited history probing attack to see which site they visited. If we wanted to protect against timing attacks like this I think we would need to just have the browser itself ensure all network traffic has unpredictable timing (and remove the visited URLs features). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[widgets] blog post on recent Dig Sig spec
Hi, Two blog posts have recently appeared which provide good critical feedback on the Widgets 1.0: Digital Signatures specs: http://sfsecurity.wordpress.com/2009/04/08/code-signing-can-be-trusted-but-not-blindly/#comment-12 http://www.links.org/?p=600 Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
RE: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]
Hi Art, All, If there is no use case for accessing this information (I was after why you would want to access this information because I think just saying it might be interesting to do so isn't justification enough), then I think my original proposal holds - make the signature files unavailable to the widget at runtime. For clarification I was not suggesting that an API should be added to the DigSig spec but rather that some of the information could be exposed via an API defined in the APIs and Events spec. But I don't think this is necessary or worth the additional specification effort. Thanks, Mark -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: 07 April 2009 21:57 To: Priestley, Mark, VF-Group Cc: Hirsch Frederick (Nokia-CIC/Boston); Web Applications Working Group WG Subject: Re: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets] On Apr 2, 2009, at 6:01 PM, ext Priestley, Mark, VF-Group wrote: Comments inline. FWIW my view is that if there is a valid use case for a widget being able to access information in a signature file, either it should access this information using an API or we should add further restrictions to the widget digital signature format and processing. Since Frederick's use cases [1] didn't convince you, what specific change(s) do you think is needed in the Widgets DigSig spec? Defining an API in this spec doesn't seem like a good approach. -Regards, Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0017.html
Re: HTML 5 Database Storage Does Not Enable Chaining Transactions
As a followup to my post starting The scenario where I need to use HTML 5 Database storage requires storing a tree of data My particular need can be met by generating identifiers in software, rather than having the database do so. This also eliminates the need to chain database calls. However, there are related scenarios where that strategy doesn't work, including most scenarios where what gets written to the database depends in more complicated ways on what has been written. And even when there's no need to chain database calls, if one has several outstanding calls to the database, it would be very helpful to know which call triggered a callback. One example is issuing several database calls for data to update several different regions on a page -- when the data is returned, it will not indicate _which_ region on the page is to be updated (unless extra effort is made, such as storing that info in the database, which would pollute it. So, I still think there is a need to pass a variable from the code calling the database, to the callback. JavaScript has closures, which would do the job in many cases, but other languages don't.
Re: Web Storage SQL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giovanni Campagna wrote: As far as I understand from this discussion and from the linked posts, there are currently three database types and their respective query languages: - relational databases and SQL - Ecmascript objects and JSONQuery - XML databases and XQuery Each one has its own merits: for example XML allows to use XML serialization and DOM, relational databases allow great masses of data with fast indexing, ES object allow for both typed and untyped (object) data. In addition, each one has its own community of followers. So why not adding a parameter on openDatabase() to specify what kind of database we want (and what kind of query language we will use)? I mean something like openDatabase(name, version, type, displayName, estimatedSize) where type can be any string so, for example, type = sql uses the standard SQL, type=sqlite uses SQLite extensions, type=-vendor-xyz is a vendor specific extension, etc. I think you would have to take the lite out the db name ;). I would think supporting three completely different data paradigms and three different query languages would be a large system. Also, just a clarification, our JSON/JS-oriented object style storage system in Persevere that uses JSONQuery has fully indexed tables, so it achieves the some level of scalability for querying massive tables (using JSONQuery) as its relational counterparts (that use SQL). I don't know of any scalability advantage to SQL. The same may be true of XQuery, I haven't dealt with XML dbs. - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknd8hcACgkQ9VpNnHc4zAy3owCdEpThZk9wpKBZZSJIlEtWg6T8 8owAn3s1dLUOHX+AHF3OqpIp3vZ9lCMm =BlmS -END PGP SIGNATURE-
Re: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]
On Thu, Apr 9, 2009 at 2:17 PM, Priestley, Mark, VF-Group mark.priest...@vodafone.com wrote: Hi Art, All, If there is no use case for accessing this information (I was after why you would want to access this information because I think just saying it might be interesting to do so isn't justification enough), then I think my original proposal holds - make the signature files unavailable to the widget at runtime. For clarification I was not suggesting that an API should be added to the DigSig spec but rather that some of the information could be exposed via an API defined in the APIs and Events spec. But I don't think this is necessary or worth the additional specification effort. FWIW, I agree with Mark. Kind regards, Marcos -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: 07 April 2009 21:57 To: Priestley, Mark, VF-Group Cc: Hirsch Frederick (Nokia-CIC/Boston); Web Applications Working Group WG Subject: Re: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets] - Show quoted text - On Apr 2, 2009, at 6:01 PM, ext Priestley, Mark, VF-Group wrote: Comments inline. FWIW my view is that if there is a valid use case for a widget being able to access information in a signature file, either it should access this information using an API or we should add further restrictions to the widget digital signature format and processing. Since Frederick's use cases [1] didn't convince you, what specific change(s) do you think is needed in the Widgets DigSig spec? Defining an API in this spec doesn't seem like a good approach. -Regards, Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0017.html -- Marcos Caceres http://datadriven.com.au
Re: Web Storage SQL
Giovanni Campagna wrote: So why not adding a parameter on openDatabase() to specify what kind of database we want (and what kind of query language we will use)? I mean something like openDatabase(name, version, type, displayName, estimatedSize) where type can be any string so, for example, type = sql uses the standard SQL, type=sqlite uses SQLite extensions, type=-vendor-xyz is a vendor specific extension, etc. How does this solve the original no such thing as standard SQL, really issue? -Boris
Re: Web Storage SQL
2009/4/9 Boris Zbarsky bzbar...@mit.edu: Giovanni Campagna wrote: So why not adding a parameter on openDatabase() to specify what kind of database we want (and what kind of query language we will use)? I mean something like openDatabase(name, version, type, displayName, estimatedSize) where type can be any string so, for example, type = sql uses the standard SQL, type=sqlite uses SQLite extensions, type=-vendor-xyz is a vendor specific extension, etc. How does this solve the original no such thing as standard SQL, really issue? We have a standard SQL, and we have DBMS-specific extensions (for SQLite, for MySQL, for SQLServer, etc.). The latest version is ISO/IEC 9075:2008 Information technology -- Database languages -- SQL, released in 2008, but actively being revised, according to the ISO page. As usual, if you want interoperability, you use the existing, implemented, standard (or you ask the ISO to produce an updated standard with new features), else you use extensions. -Boris Giovanni
Re: Do we need to rename the Origin header?
Ian Hickson wrote on 4/9/2009 1:42 AM: On Thu, 9 Apr 2009, Bil Corry wrote: For example, imagine instead you visit a malicious site, and it wants to phish your banking credentials. But rather than choosing a random bank and hoping you bank there, it instead launches a series of timing attacks against the top 30 banks, determines which bank(s) you're logged into, then tries phishing against the one you're logged into. CORS-Origin can't help, but a robust Origin could. You could just do a timing attack against non-login-protected assets that are only shown while logged in, or even just do timing attacks against any cached resource from the site, to see if they visited it. Or heck, you could just do a regular :visited history probing attack to see which site they visited. If we wanted to protect against timing attacks like this I think we would need to just have the browser itself ensure all network traffic has unpredictable timing (and remove the visited URLs features). My point is that a robust Origin moves us closer to better security controls, perhaps not all the way, but certainly much closer than CORS-Origin gets us. - Bil
Re: Web Storage SQL
Giovanni Campagna wrote: We have a standard SQL, and we have DBMS-specific extensions (for SQLite, for MySQL, for SQLServer, etc.). The latest version is ISO/IEC 9075:2008 Information technology -- Database languages -- SQL, released in 2008, but actively being revised, according to the ISO page. Sort of. Extensions implies that as long as you write a query to the ISO standard in question the behavior will be the same in all databases and that you have to go out of your way to write non-interoperable queries. This is not the case. A query written based on that ISO standard has different behavior in different databases, in many cases. So just telling web authors write queries based on this standard and they will work is not sufficient. Let's ignore the fact that most web authors wouldn't be able to even get their hands on this standard to see whether their query complies with it without paying a fairly hefty sum [1]. You could also require UAs to implement queries exactly per this standard. Vladimir mentioned as a possible option in his original post. This is definitely the way forward (with either this SQL definition or some subset thereof) As usual, if you want interoperability, you use the existing, implemented, standard (or you ask the ISO to produce an updated standard with new features), else you use extensions. Use of the existing standard by authors doesn't give interoperability. -Boris [1] http://www.iso.org/iso/search.htm?qt=9075searchSubmit=Searchsort=reltype=simplepublished=on tells me that to get just the parts of ISO 9075:2008 that are obviously necessary to be able to do anything whatsoever will cost me either about $290 or $770 depending on what's in part 2 of the spec. I'm assuming none of parts 3,4,9,10,11,13,14 are relevant to our use case; this is probably a good assumption for most of them. That's for getting a PDF, of course; the PDF on CD prices are somewhat higher, and there seem to be no other provisions for looking at this specification.
Re: Web Storage SQL
Hi :-), Le 9/04/09 17:29, Giovanni Campagna a écrit : 2009/4/9 Boris Zbarskybzbar...@mit.edu: Giovanni Campagna wrote: So why not adding a parameter on openDatabase() to specify what kind of database we want (and what kind of query language we will use)? I mean something like openDatabase(name, version, type, displayName, estimatedSize) where type can be any string so, for example, type = sql uses the standard SQL, type=sqlite uses SQLite extensions, type=-vendor-xyz is a vendor specific extension, etc. How does this solve the original no such thing as standard SQL, really issue? We have a standard SQL, and we have DBMS-specific extensions (for SQLite, for MySQL, for SQLServer, etc.). The latest version is ISO/IEC 9075:2008 Information technology -- Database languages -- SQL, released in 2008, but actively being revised, according to the ISO page. As usual, if you want interoperability, you use the existing, implemented, standard (or you ask the ISO to produce an updated standard with new features), else you use extensions. A Database Abstract Layer (DAL, i.e. a system that enables user to select the Relational Database Management System, RDMS, to use) is a good idea but it does not sound standard anymore. I mean: we are postponing the problem, because who, why and how will decide what RDMS must be implemented? What about XML based database? Best regards. -- Ivan Enderlin Developper of Hoa Framework http://hoa-project.net/
[Fwd: Re: Web Storage SQL]
Message original Sujet: Re: Web Storage SQL Date : Thu, 9 Apr 2009 18:28:10 +0200 De :Giovanni Campagna scampa.giova...@gmail.com Pour : Ivan Enderlin @ Hoa w...@hoa-project.net 2009/4/9 Ivan Enderlin @ Hoaw...@hoa-project.net: Hi :-), Le 9/04/09 17:29, Giovanni Campagna a écrit : 2009/4/9 Boris Zbarskybzbar...@mit.edu: Giovanni Campagna wrote: So why not adding a parameter on openDatabase() to specify what kind of database we want (and what kind of query language we will use)? I mean something like openDatabase(name, version, type, displayName, estimatedSize) where type can be any string so, for example, type = sql uses the standard SQL, type=sqlite uses SQLite extensions, type=-vendor-xyz is a vendor specific extension, etc. How does this solve the original no such thing as standard SQL, really issue? We have a standard SQL, and we have DBMS-specific extensions (for SQLite, for MySQL, for SQLServer, etc.). The latest version is ISO/IEC 9075:2008 Information technology -- Database languages -- SQL, released in 2008, but actively being revised, according to the ISO page. As usual, if you want interoperability, you use the existing, implemented, standard (or you ask the ISO to produce an updated standard with new features), else you use extensions. A Database Abstract Layer (DAL, i.e. a system that enables user to select the Relational Database Management System, RDMS, to use) is a good idea but it does not sound standard anymore. I mean: we are postponing the problem, because who, why and how will decide what RDMS must be implemented? What about XML based database? Best regards. First, we have sql. This is the start of the Database proposals, and all conforming implementation must expose an SQL interface that is conforming to the ISO standard I cited before. Then we could add xml and json (or other formats) as standard to be implemented by everyone. This is only a choice of query language and data model (trees, objects and tables), not of the DBMS (SQLite vs SQLServer), and I hope this choice will be made by the WebApps Working Group, as this is the WG chartered for the WebStorage proposal. Thirdly, we have extension, in the form of -vendor-dbms. For example, I may expect that IE will have a -ms-sqlserver. These formats are by definition out of standard, but they allow the use of extensions beyond the ISO SQL standard. -- Ivan Enderlin Developper of Hoa Framework http://hoa-project.net/ Giovanni
Re: Web Storage SQL
2009/4/9 Boris Zbarsky bzbar...@mit.edu: Giovanni Campagna wrote: We have a standard SQL, and we have DBMS-specific extensions (for SQLite, for MySQL, for SQLServer, etc.). The latest version is ISO/IEC 9075:2008 Information technology -- Database languages -- SQL, released in 2008, but actively being revised, according to the ISO page. Sort of. Extensions implies that as long as you write a query to the ISO standard in question the behavior will be the same in all databases and that you have to go out of your way to write non-interoperable queries. Yes. With extensions I mean writing start transaction instead of begin, using the backquotes instead of double quotes for identifires, using INET and spatial data types, using table options... This is not the case. A query written based on that ISO standard has different behavior in different databases, in many cases. This is obviously an implementation bug, and should be corrected in the DBMS, not in the browser or in the web page. So just telling web authors write queries based on this standard and they will work is not sufficient. Let's ignore the fact that most web authors wouldn't be able to even get their hands on this standard to see whether their query complies with it without paying a fairly hefty sum [1]. We have tutorials and guides for that You could also require UAs to implement queries exactly per this standard. Vladimir mentioned as a possible option in his original post. This is definitely the way forward (with either this SQL definition or some subset thereof) But some extensions are useful (like spatial data types or non-transactional database engines): I don't see why we should not allow them, in a vendor (browser or dbms) specific form. As usual, if you want interoperability, you use the existing, implemented, standard (or you ask the ISO to produce an updated standard with new features), else you use extensions. Use of the existing standard by authors doesn't give interoperability. Again, this is an implementation bug, not something that should affect authors -Boris [1] http://www.iso.org/iso/search.htm?qt=9075searchSubmit=Searchsort=reltype=simplepublished=on tells me that to get just the parts of ISO 9075:2008 that are obviously necessary to be able to do anything whatsoever will cost me either about $290 or $770 depending on what's in part 2 of the spec. I'm assuming none of parts 3,4,9,10,11,13,14 are relevant to our use case; this is probably a good assumption for most of them. That's for getting a PDF, of course; the PDF on CD prices are somewhat higher, and there seem to be no other provisions for looking at this specification. Unfortunately, these are the problems of ISO standards. We cannot change that. Giovanni
HTML5 Origin (aka IETF Origin draft)
I wanted to clarify something in the IETF Origin draft[1], which is now going to serve as the basis for HTML5's Origin. Section 5 requires that when a user agent provides the Origin header, it must either send null or the ASCII serialization of the origin. ASCII serialization (and Unicode serialization) stipulates that if an origin is not a scheme/host/port tuple, then it must return null. Section 2 allows implementations to define other types of origins in addition to the scheme/host/port tuple. So my question is, if a user agent defines another type of origin, but is required to send null for it in the Origin header, is there some other use for defining other types of origins? - Bil [1] http://www.ietf.org/internet-drafts/draft-abarth-origin-00.txt
Re: ISSUE-83 (digsig should not be read at runtime): Instantiated widget should not be able to read digital signature [Widgets]
On 4/9/09 3:56 PM, Arthur Barstow wrote: On Apr 9, 2009, at 9:52 AM, ext Marcos Caceres wrote: On Thu, Apr 9, 2009 at 2:17 PM, Priestley, Mark, VF-Group mark.priest...@vodafone.com wrote: Hi Art, All, If there is no use case for accessing this information (I was after why you would want to access this information because I think just saying it might be interesting to do so isn't justification enough), then I think my original proposal holds - make the signature files unavailable to the widget at runtime. For clarification I was not suggesting that an API should be added to the DigSig spec but rather that some of the information could be exposed via an API defined in the APIs and Events spec. But I don't think this is necessary or worth the additional specification effort. FWIW, I agree with Mark. Please propose text that will address your concerns. In the PC spec, I would add something like: A user agent MUST make the digital signature available only to implementations of the [Widgets-DigSig] specification. A user agent MUST NOT allow read access to any digital signature in the widget package at runtime. In other words, a user agent MUST NOT allow a start file, or any other file or resource inside or outside the context of the widget (e.g., a script or stylesheet), or API, or feature, to read any digital signature file within the widget package. At runtime, a user agent MUST make it seem as if digital signatures do not exist in the widget package by, for example, excluding them from any file listings, and not allowing them to be accessed via a URI. That's just some quick draft text, please feel free to change, add, or whatever. Kind regards, Marcos
Re: Web Storage SQL
On Apr 8, 2009, at 2:51 PM, Vladimir Vukicevic wrote: There's been a lot of interest around the Web Storage spec (formerly part of whatwg HTML5), which exposes a SQL database to web applications to use for data storage, both for online and offline use. It presents a simple API designed for executing SQL statements and reading result rows. But there's an interesting problem with this; unlike the rest of the HtML5, this section defines a core piece of functionality in terms of an undefined chunk referenced as SQL. Treating SQL as an undefined chunk is not unprecedented. Most database APIs platforms do not require a restricted syntax of SQL to be supported in the underlying database. For example, X/OPEN SQL CLI [1] was based on SQL 92 but its successors (JDBC, ODBC) go beyond this and support any additional SQL syntax supported by the underlying data source. The initial implementations of Web Storage are both based on SQLite, and expose the dialect of SQL understood by SQLite to web content. I'm actually a big fan of SQLite, and was one of the advocates for pulling it into the Gecko platform. However, SQLite implements a variant of SQL, with a number of deviations from other SQL engines, especially in terms of the types of data that can be placed in columns. Data types are certainly relevant here because with JavaScript you never know what arguments will translate to which values and types. For example, what does NULL translate to and what about undefined? My observation is that undefined is translated to the text value undefined and NULL translates to the SQL NULL. But there is no specification for this behavior. Web content that is created to use database storage with SQLite as the backing is unlikely to work with any other backend database. Similarly, if another database was chosen as a browser's backing implementation, web content that works with it is unlikely to work with anything else. This is a serious interop problem, the root of which is that there really isn't a useful core SQL standard. SQL92 is generally taken as a base, but is often extended or altered by implementations. Even beyond the parser issues (which could be resolved by defining a strict syntax to be used by Web Storage), the underlying implementation details will affect results. There is inherent challenge in embedding as potent a capability as data access inside a platform since there is a lot of variation in its own design and use. Still, the question in my mind is not whether an unanchored reference to SQL is fine as much as whether SQL is the right way (and for years to come, the only structured way) to think of Web application's (locally persistent) data. So, the only option is for the Web Storage portion of the spec to state do what SQLite does. This isn't specified in sufficient detail anywhere to be able to reimplement it from the documents, so it would be even worse — do what this exact version of SQLite does, because there are no guarantees that SQLite won't make any incompatible changes. For example, a future SQLite 4 may introduce some changes or some new syntax which wouldn't be supported by earlier versions. Thus, it requires every single browser developer to accept SQLite as part of their platform. This may not be possible for any number of reasons, not the least of which is it essentially means that every web browser is on the hook for potential security issues within SQLite. Instead of all of this, I think it's worth stepping back and consider exactly what functionality web developers actually want. Oracle certainly supports this endeavor to understand exactly what kind of local storage capabilities are required. It's certainly much easier to say well, server developers are used to working with SQL, so let's just put SQL into the client, but it's certainly not ideal — most people working with SQL tend to end up writing wrappers to map their database into a saner object API. There is no end to how much Oracle and various other companies shield developers using their platforms from using raw SQL. There are more reasons for that than I can list here, but suffice it to say that the Web Storage spec should consider techniques that are better matched to the Web as a data access platform - i.e., in terms of URLs and HTTP methods. So, I would propose stepping back from Web Storage as written and looking at the core pieces that we need to bring to web developers. I believe that the solution needs to have a few characteristics. First, it should be able to handle large data sets efficiently; in particular, it should not require that the entire data set fit into memory at one time. Second, it should be able to execute queries over the entire dataset. Finally, it should integrate well with the web, and in particular with JavaScript. With these needs in
Re: Do we need to rename the Origin header?
On Thu, Apr 9, 2009 at 8:48 AM, Bil Corry b...@corry.biz wrote: My point is that a robust Origin moves us closer to better security controls, perhaps not all the way, but certainly much closer than CORS-Origin gets us. I think we should focus on clear use cases and techniques that address those use cases. For example, Mozilla-Origin is useful for mitigating ClickJacking whereas CORS-Origin is not. Adam
Re: Web Storage SQL
On Apr 9, 2009, at 8:19 AM, Boris Zbarsky wrote: Giovanni Campagna wrote: So why not adding a parameter on openDatabase() to specify what kind of database we want (and what kind of query language we will use)? I mean something like openDatabase(name, version, type, displayName, estimatedSize) where type can be any string so, for example, type = sql uses the standard SQL, type=sqlite uses SQLite extensions, type=-vendor-xyz is a vendor specific extension, etc. How does this solve the original no such thing as standard SQL, really issue? I agree that no such thing as standard SQL (or rather the fact that implementations all have extensions and divergences from the spec) is a problem. But I am not sure inventing a brand new query language and database model as proposed by Vlad is a good solution to this problem. A few thoughts off the cuff in no particular order: 1) Applications are starting to be deployed which use the SQL-based storage API, such as the mobile version of GMail. So it may be too late for us to remove SQL storage from WebKit entirely. If we want this content to interoperate with non-WebKit-based user agents, then we will ultimately need a clear spec for the SQL dialect to use, even if we also added an OODB or a relational database using some other query language. 2) It's true that the server side code for many Web sites uses an object-relational mapping layer. However, so far as I know, very few use an actual OODB. Relational databases are dominant in the market and OODBs are a rarely used niche product. Thus, I question Vlad's suggestion than a client-side OODB would sufficiently meet the needs of authors. Rather, we should make sure that the platform supports adding an object-relational mapping on top of SQL storage. 3) It's not obvious to me that designing and clearly specifying a brand new query language would be easier than specifying a dialect of SQL. Note that this may require implementations to actually parse queries themselves and possibly change them, to ensure that the accepted syntax and semantics conform to the dialect. We are ok with this. 4) It's not obvious to me that writing a spec for a query language with (afaik) a single implementation, such as jLINQ, is easier than writing a clear and correct spec for what SQLite does or some subset thereof. Thus, I think the best path forward is to spec a particular SQL dialect, even though that task may be boring and unpleasant and not as fun as inventing a new kind of database. Regards, Maciej
Re: Web Storage SQL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maciej Stachowiak wrote: On Apr 9, 2009, at 8:19 AM, Boris Zbarsky wrote: Giovanni Campagna wrote: So why not adding a parameter on openDatabase() to specify what kind of database we want (and what kind of query language we will use)? I mean something like openDatabase(name, version, type, displayName, estimatedSize) where type can be any string so, for example, type = sql uses the standard SQL, type=sqlite uses SQLite extensions, type=-vendor-xyz is a vendor specific extension, etc. How does this solve the original no such thing as standard SQL, really issue? I agree that no such thing as standard SQL (or rather the fact that implementations all have extensions and divergences from the spec) is a problem. But I am not sure inventing a brand new query language and database model as proposed by Vlad is a good solution to this problem. A few thoughts off the cuff in no particular order: 1) Applications are starting to be deployed which use the SQL-based storage API, such as the mobile version of GMail. So it may be too late for us to remove SQL storage from WebKit entirely. If we want this content to interoperate with non-WebKit-based user agents, then we will ultimately need a clear spec for the SQL dialect to use, even if we also added an OODB or a relational database using some other query language. 2) It's true that the server side code for many Web sites uses an object-relational mapping layer. However, so far as I know, very few use an actual OODB. Relational databases are dominant in the market and OODBs are a rarely used niche product. Thus, I question Vlad's suggestion than a client-side OODB would sufficiently meet the needs of authors. Rather, we should make sure that the platform supports adding an object-relational mapping on top of SQL storage. First, OODB's seem to be on the rise, albiet under different titles lately (AppEngine, SimpleDB, CouchDB, Persevere). Second, when using relational DBs, most devs use ORMs to interact with the DB, so they are primarily working in the object-realm, even on the server. For situations where data is transferred to the client (in data form), devs stay in the object realm for the data transfer (JSON) and on the browser in JavaScript. I don't see why we would want to force data translation back to the relational realm in the last leg on the browser when we have worked so hard to stay within object paradigm. 3) It's not obvious to me that designing and clearly specifying a brand new query language would be easier than specifying a dialect of SQL. Note that this may require implementations to actually parse queries themselves and possibly change them, to ensure that the accepted syntax and semantics conform to the dialect. We are ok with this. I agree that we shouldn't be specifying a brand new query language. I thought the idea was looking at existing query languages that would be better fits for the web/JS environment. Nothing new would need to be invented here. 4) It's not obvious to me that writing a spec for a query language with (afaik) a single implementation, such as jLINQ, is easier than writing a clear and correct spec for what SQLite does or some subset thereof. JSONPath/JSONQuery seems like a far more mature path if an alternative to SQL is to be considered, and has a pretty good set of implementations (probably at least 5 different impls). Thus, I think the best path forward is to spec a particular SQL dialect, even though that task may be boring and unpleasant and not as fun as inventing a new kind of database. In view of point #1, this may be the best course, I don't know, but I mainly wanted to correct some of the statements above. - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkneW+oACgkQ9VpNnHc4zAzs7wCeNh6qFrbomEi/wsx2FXo5GoQG kKgAn35tW9U3iUzBoeYhfmgq9eBphoU7 =G5bP -END PGP SIGNATURE-
Re: Web Storage SQL
SQLite wasn't the first browser-accessible DBMS, nor is it the most ubiquitous choice of target. IE's Jet database engine, which is the underlying engine for Access, would seem to be the most useful target specification. After all, the overwhelming majority of what I've heard over the past decade when discussing database support in a web browser can be paraphrased as I want to port my Access application to the browser. Can I do that? Changing the storage model or semantics away from those supported by Access would seem to be a great way to throw another roadblock in front of customers whose prior desktop applications have typically relied on Access, not Oracle, and certainly not Versant et. al. ss
Re: Web Storage SQL
Maciej Stachowiak wrote: I agree that no such thing as standard SQL (or rather the fact that implementations all have extensions and divergences from the spec) is a problem. But I am not sure inventing a brand new query language and database model as proposed by Vlad is a good solution to this problem. That's fine; I'm not sure of that either. I have no particular opinion on that question, in fact. 1) Applications are starting to be deployed which use the SQL-based storage API, such as the mobile version of GMail. So it may be too late for us to remove SQL storage from WebKit entirely. This is a price of early adoption, sure. If we want this content to interoperate with non-WebKit-based user agents, then we will ultimately need a clear spec for the SQL dialect to use, even if we also added an OODB or a relational database using some other query language. That's true, but it's not a given that we want this content to interoperate as-is. Early adopters of known in-flux technologies typically realize that they might have to make changes; if a different data storage API is decided on, or if the subset of SQL that's decided on doesn't match what these apps are using, then they'll need to change. So while I agree that it might be difficult for Webkit to remove the SQL support it shipped as soon as some other approach is decided on (if that even happens), it doesn't follow that other UAs would need to ship SQL support at that point. There are strong arguments for not breaking existing content, of course, but there are also strong arguments for not having experimental implementations of early drafts completely dictate the standardization process. No opinion on your other points; this is far from my area of expertise. -Boris
