On Fri, Jul 30, 2010 at 11:51 AM, Nicholas Zakas 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 replacement for
> a wider r
On Tue, Jun 1, 2010 at 4:07 PM, Mark Frohnmayer
wrote:
> On Tue, Jun 1, 2010 at 1:02 PM, Erik Möller 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 p2p should be looked at in th
On Wed, Apr 14, 2010 at 5:23 PM, Nicholas Zakas 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:
>
> http://www.nczonline.net/blog/2010/04/13/towards-more-secure-client-si
2010/3/10 Jeremy Orlow :
> 2010/3/10 Ian Fette (イアンフェッティ)
>> 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 the new storage
>> mechanisms
"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 Robinson 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
concurrent-programmi
On Tue, Apr 7, 2009 at 6:30 PM, Brady Eidson 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 frequently, jus
On Tue, Apr 7, 2009 at 6:33 PM, Brady Eidson 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,
>> right?
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
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 lon
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 I assumed it meant a
>>> dialog box. This might be due to my experience with the 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 introdu
On Dec 11, 2007 3:02 PM, Oliver Hunt <[EMAIL PROTECTED]> wrote:
> > It's clear that most people here feel passionately that this is the
> > wrong thing to do. Perhaps it's best that we table this until
> > something like workerpools are in the spec.
>
> Worker pools do not resolve the problem, even
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" b
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 (
On Oct 31, 2007 5:40 PM, Brady Eidson <[EMAIL PROTECTED]> wrote:
> I have an alternative to propose - how about reinstating
> Database.executeSql(), and do something like this.
>
> db.executeSql("select * from table;", [], ,
> , );
I think SQLTransactionErrorCallback is redudant with
SQLStatementE
On Oct 31, 2007 5:21 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Wed, 31 Oct 2007, Timothy Hatcher wrote:
> > How is that wrong? If the first executeSql fails the error callback (if
> > any) will fire, not the normal callback.
> >
> > db.executeSql('CREATE TABLE ...', [], function(...) {
> >
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 n
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 "" and www.google.com
> thinks the database might use up
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
that the database is persistent. If the DOM became
corrupted, and you refresh the page or restart the browser, there's a
good chance that your DOM will no longer be corrupted. If your
Database is corrupted and you refresh the page or restart the browser,
your Database is still corrupted.
&
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 the
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/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 structur
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
On 10/17/07, Brady Eidson <[EMAIL PROTECTED]> wrote:
> Assuming using sqlite for the back end, I just wrote a quick little
> driver that creates a table with 10 columns, then inserts the exact
> same value into the table 20,000 times.
> I then ran the exact same test that does the exact same thing,
a high-concurrency system
a bunch of bare statements is likely to allow more performance than
the same statements in a transaction. I'm concerned that making
transactions implicit to address an implementation detail like
performance may cause unforseen correctness issues.
On 10/16/07,
On 10/17/07, Ian Hickson <[EMAIL PROTECTED]> wrote:
> On Fri, 5 Oct 2007, Scott Hess wrote:
> > 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 i
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
> "sta
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 spe
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 thi
e rows from every table with SQL
> 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 cou
t and
> upload them 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:[E
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 ge
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 s
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 for
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:
>
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
> e
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 t
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 ag
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 tra
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:
> > * Database that is full
>
> This currently just reports an error with code 1, like everything else,
> but in due course w
42 matches
Mail list logo
