On Fri, Jul 30, 2010 at 11:51 AM, Nicholas Zakas nza...@yahoo-inc.com wrote:
And I totally agree, this is not a strong security feature, and that’s not
the intent. The intent is just to give an extra measure of control of the
lifetime of the data to bring Web Storage closer to being a
On Tue, Jun 1, 2010 at 4:07 PM, Mark Frohnmayer
mark.frohnma...@gmail.com wrote:
On Tue, Jun 1, 2010 at 1:02 PM, Erik Möller emol...@opera.com wrote:
So, what would the minimal set of limitations be to make a UDP WebSocket
browser-safe?
-No listen sockets
Only feedback here would be I think
On Wed, Apr 14, 2010 at 5:23 PM, Nicholas Zakas nza...@yahoo-inc.com wrote:
I tried to articulate some of my thoughts as to why a generate purpose
crypto isn’t enough to be useful and why trying to tack onto local storage
could get messy:
2010/3/10 Jeremy Orlow jor...@chromium.org:
2010/3/10 Ian Fette (イアンフェッティ) ife...@google.com
As I talk with more application developers (both within Google and at
large), one thing that consistently gets pointed out to me as a problem is
the notion of the opaqueness of storage quotas in all of
user agent MAY release means that people will write code which works
now, and later the browser vendor will make a change that will break
their code. Who is at fault? We all know that the browser vendor is
at fault!
Suggest the user agent SHALL release the storage mutex on any API
operation
On Thu, Sep 10, 2009 at 2:38 PM, James Robinsonjam...@google.com wrote:
I also strongly feel that giving web
developers access to locking mechanisms is a bad idea - it hasn't been a
spectacular success in any other language.
I think that you can either give web developers a strong set of
On Tue, Apr 7, 2009 at 6:33 PM, Brady Eidson beid...@apple.com wrote:
On Apr 7, 2009, at 6:24 PM, Jeremy Orlow wrote:
Both would lead to bizarre behavior where data that the application
thought was saved really wasn't.
This matches up with how most private browsing sessions handle cookies,
On Tue, Apr 7, 2009 at 6:30 PM, Brady Eidson beid...@apple.com wrote:
On Apr 7, 2009, at 6:19 PM, Ian Fette (イアンフェッティ) wrote:
I think that doing option 3, and perhaps providing a way for the app to
know that we're in this mode so it can do whatever is appropriate (saving to
the cloud more
On Wed, Nov 26, 2008 at 8:58 AM, Aaron Boodman [EMAIL PROTECTED] wrote:
On Wed, Nov 26, 2008 at 3:46 AM, Ian Hickson [EMAIL PROTECTED] wrote:
We could have a .writeTransaction() and a .readTransaction(), where the
former always run in isolation.
Any preferences?
My preference is for
On Fri, May 23, 2008 at 9:48 AM, Aaron Boodman [EMAIL PROTECTED] wrote:
I noticed one unfortunate thing about the new Database API. Because
the executeSql() callback holds open the transaction, it is easy to
accidentally do intensive work inside there and hold open the
transaction too long. A
On Wed, May 14, 2008 at 11:37 AM, fantasai
[EMAIL PROTECTED] wrote:
Ian Hickson wrote:
On Tue, 13 May 2008, Zachary Carter wrote:
FWIW, in my first encounter with HTML5 dialog I assumed it meant a
dialog box. This might be due to my experience with the dialog element in
XUL[1], which is used
On Thu, Feb 14, 2008 at 5:44 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
On Thu, Feb 14, 2008 at 3:05 PM, Geoffrey Garen [EMAIL PROTECTED] wrote:
Since postMessage API is looking more an more like the Gears worker
messaging API (or better), can we go one step further and introduce
On Dec 11, 2007 11:22 AM, Aaron Boodman [EMAIL PROTECTED] wrote:
Or does
globalStorage not guarantee that data is written when the setter
returns?
A thing I've been thinking about for Gears would be the ability to
spin up an in-memory/async session database, with the sense of
session being the
On Oct 31, 2007 5:20 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Wed, 31 Oct 2007, Scott Hess wrote:
I think one could work around this within the current spec something
like:
var success = true;
db.transaction(function (t) {
t.executeSql('insert into x values (?)', [y
On Oct 24, 2007 10:38 AM, Brady Eidson [EMAIL PROTECTED] wrote:
Armed with these two option arguments, a single UI prompt similar to:
www.google.com wants to create a database on your hard drive. The
purpose of the database is for DatabaseDescription and www.google.com
thinks the database
On Oct 26, 2007 3:51 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 25 Oct 2007, Brady Eidson wrote:
Step 9 of the transaction steps stipulates that if the transaction fails
to commit, the script will get an SQLTransactionErrorCallback indicating
this failure. However, there is no final
On 10/19/07, Brady Eidson [EMAIL PROTECTED] wrote:
There is no standard way in SQL that I know of to get the list of
tables in a database.
In SQLite you can enumerate tables out of sqlite_master, but that
should not be encouraged.
What are people's thoughts about adding this to the API?
If the statement to executeSql() is invalid, then an exception will be
raised immediately, which can be caught by wrapping the call to
executeSql() with an exception handler. If there is an error in the
course of executing the statement, it will be exposed by the errorCode
in the callback. If
will no longer be corrupted. If your
Database is corrupted and you refresh the page or restart the browser,
your Database is still corrupted.
On Tue, 16 Oct 2007, Scott Hess wrote:
I think that if the user agent did detect corruption and nuke the
database from orbit, then it would be reasonable
On 10/17/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:
I'm not sure what other reasons Scott sees for (2). I do think it
would aid authoring clarity to have the word transaction in the API,
even if the model of how they are managed is much the same as
currently (so you can't forget to close
On 10/17/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Oct 17, 2007, at 1:14 PM, Scott Hess wrote:
I think my concern is in two related bits:
A) As things currently stand, the developer simply can't roll their
own transaction structure. Passing BEGIN, COMMIT, or ROLLBACK
On 10/17/07, Aaron Boodman [EMAIL PROTECTED] wrote:
This is the first thing that makes me question the current implicit
transaction API :-(. Maybe adding a executeSqlInTransaction() would be
smarter. You can then separate the two meanings of SQLCallback:
- getting results of a sql call
-
On 10/15/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Mon, 15 Oct 2007, Scott Hess wrote:
Whoa! I just realized that there's another group, constraint failures.
These are statements which will sometimes succeed, sometimes fail. As
currently spec'ed, it looks like a constraint failure
On 10/16/07, Geoffrey Garen [EMAIL PROTECTED] wrote:
It would be nice to have a way to indicate to the script There was
a catastrophic event and we reset your database, assume you're
starting over from scratch.
In general, I'm not sure how useful it is to know that you're
starting over
On 10/15/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Fri, 5 Oct 2007, Scott Hess wrote:
Reviewing SQLite's error list, the things that MAY have utility to
report more finely might be:
* LOCKED, where you failed because someone else has things locked.
Presumably if a single thread
On 10/14/07, Kristof Zelechovski [EMAIL PROTECTED] wrote:
It is possible to recover from a database full error. You can dump the data
to a slower device for example. While this action would not make the
database operable again, you would at least avoid losing data.
This is true in the
to a backup server via HTTP. While this need not be the most
efficient and secure way to go, there are no software obstacles against.
Better methods may be invented.
Best regards,
Chris
-Original Message-
From: Scott Hess [mailto:[EMAIL PROTECTED]
Sent: Sunday, October 14, 2007 3:47 PM
queries. That is what Kristof was inferring.
On Oct 14, 2007, at 7:16 AM, Scott Hess wrote:
I think this does imply an ability to delete the entire local
database, which might be a reasonable API addition. Even short of
this case, you could also consider the named databases as part of an
app's
On 10/12/07, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Fri, 12 Oct 2007 20:46:52 +0200, Ian Hickson [EMAIL PROTECTED] wrote:
Certainly that would be reasonable. I have added it. People should let me
know if they want me to remove or add error codes, by the way.
I think there should be
I think I agree with this. Apps should either use the database in a
versioned form, or an unversioned form, but never both. Insofar as
there is some subset of the database which is trustworthy to use in
unversioned form, it should be easy enough to just spin up a separate
unversioned database
On 9/24/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 20 Sep 2007, Anne van Kesteren wrote:
The SQL API doesn't seem to define how to deal with errors, such as:
snip
* Database that is full
This currently just reports an error with code 1, like everything else,
but in due course we
On 9/24/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Sat, 22 Sep 2007, Timothy Hatcher wrote:
The callback syntax is nice but the implicit thread-global transaction
is confusing and can lead to programmer error and unneeded database
locking.
There isn't really a thread-global transaction,
On 9/24/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Sun, 23 Sep 2007, David wrote:
What if I want to handle the RS by blocks of 100 rows ?
Why wouldn't you just want to do everything?
For the case of a database with a 5M size limit, never.
If app developers, users, and browsers all agree
It may be worthwhile for Database to export a quote(arg) function,
which will quote the argument in the appropriate manner for use in
constructing a statement. This is useful for cases where it is
challenging to reduce something to a static SQL statement with bind
parameters. [A common case for
On 10/5/07, Scott Hess [EMAIL PROTECTED] wrote:
In the first case, since we're working within the browser, there's
generally really nothing to be done, so most stuff falls to the second
case. At that point, it would be useful to have a human-readable
error string generated by the library
Also, in case of no bind arguments, Gears allows the parameter to be
either empty or null or omitted (that not being an option in this
case).
-scott
On 10/5/07, Aaron Boodman [EMAIL PROTECTED] wrote:
To clarify, my proposed alternative is that the second argument should
just be an array:
36 matches
Mail list logo
