Re: [IndexedDB] question about description argument of IDBFactory::open()
I don't feel strongly. I'll file a bug for our proposed solution. On Thu, Aug 12, 2010 at 1:01 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 11, 2010 at 4:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Aug 11, 2010 at 10:33 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 11, 2010 at 1:30 PM, Andrei Popescu andr...@google.com wrote: On Wed, Aug 11, 2010 at 8:45 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 11, 2010 at 11:50 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 10, 2010 at 12:26 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 10, 2010 at 11:30 AM, Andrei Popescu andr...@google.com wrote: On Mon, Aug 9, 2010 at 11:36 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:31 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 9, 2010 at 3:24 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:15 PM, Andrei Popescu andr...@google.com wrote: On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow jor...@chromium.org wrote: I'm pretty sure opening a database with a different description is actually already specified: the new one takes precedent. Take a look at the algorithm for database opening; I'm pretty sure it's there. When talking to Andrei earlier tonight I thought we'd probably want to make it optional, but now I'm thinking maybe we shouldn't. You're right, Shawn, that the description can be useful for many reasons. And although it seems redundant for a developer to pass in the description every time, I actually can't think of any reason why a developer wouldn't want to. Actually, I think it's pretty inconvenient to have to specify a description every time, especially since I am not sure developers would want to change the description very often. I think we should allow a null string for future connections as Shawn suggested. How do developers distinguish between when they're opening a database for the first time or not? Normally they'd look at the version, but that's not available until _after_ you've supplied the description (and presumably some UAs might have asked the user if it's OK or something like that). If the spec has a way to enumerate databases (something we've talked about doing) then it's possible that the developer could decide whether or not to pass in a version string that way. But why would they do this? So the only possible reason I could see for someone doing this is if they open a database in several places in one page and they can somehow guarantee that one of them happens first. The first question here would be but why?. And the second question is whether we trust users to for sure know the ordering that things are opened. On the other hand, it doesn't seem that hard to supply a description every time it's opened. I mean you just define it in one places within your script and use that. Or, better yet, just save the database to a variable and call open once early on in initialization. That'll make things less async anyway. Am I missing something here? I have actually been thinking that it's likely fairly common to be opening a database in several different locations and know which ones should always be reopening an existing database. I don't have any data on this though. Neither do I. Well, if we make it optional based on the assumption this is true, maybe we could spec it such that opening a database for the first time with no description is an error? Or we just remove description all together if it's not going to be dependable? Thinking more about it, do we really want this string to be displayed to the user? What happens if the browser is using one locale and the string is in another? To me, the description is something internal to the application, not something intended for the end-user. I think we should remove it altogether if we don't have a good use case for it. Also there are security concerns. For example, it'd be hard to use the description in a useful way without trusting what it says. Which isn't always possible. Also, thinking about it, I'm not sure I see much of a use case for users managing (for example deleting) individual databases. (For many of the same reasons as why we wouldn't let users delete individual ObjectStores.) The main problem is that there's a risk that apps will break if one
Re: [IndexedDB] question about description argument of IDBFactory::open()
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349 One quesiton though: if they pass in null or undefined, do we want to interpret this as the argument not being passed in or simply let them convert to undefined and null (which is the default behavior in WebIDL, I believe). I feel somewhat strongly we should do the former. Especially since the latter would make it impossible to add additional parameters to .open() in the future. J On Thu, Aug 12, 2010 at 11:37 AM, Jeremy Orlow jor...@chromium.org wrote: I don't feel strongly. I'll file a bug for our proposed solution. On Thu, Aug 12, 2010 at 1:01 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 11, 2010 at 4:05 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Aug 11, 2010 at 10:33 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 11, 2010 at 1:30 PM, Andrei Popescu andr...@google.com wrote: On Wed, Aug 11, 2010 at 8:45 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 11, 2010 at 11:50 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 10, 2010 at 12:26 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 10, 2010 at 11:30 AM, Andrei Popescu andr...@google.com wrote: On Mon, Aug 9, 2010 at 11:36 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:31 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 9, 2010 at 3:24 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:15 PM, Andrei Popescu andr...@google.com wrote: On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow jor...@chromium.org wrote: I'm pretty sure opening a database with a different description is actually already specified: the new one takes precedent. Take a look at the algorithm for database opening; I'm pretty sure it's there. When talking to Andrei earlier tonight I thought we'd probably want to make it optional, but now I'm thinking maybe we shouldn't. You're right, Shawn, that the description can be useful for many reasons. And although it seems redundant for a developer to pass in the description every time, I actually can't think of any reason why a developer wouldn't want to. Actually, I think it's pretty inconvenient to have to specify a description every time, especially since I am not sure developers would want to change the description very often. I think we should allow a null string for future connections as Shawn suggested. How do developers distinguish between when they're opening a database for the first time or not? Normally they'd look at the version, but that's not available until _after_ you've supplied the description (and presumably some UAs might have asked the user if it's OK or something like that). If the spec has a way to enumerate databases (something we've talked about doing) then it's possible that the developer could decide whether or not to pass in a version string that way. But why would they do this? So the only possible reason I could see for someone doing this is if they open a database in several places in one page and they can somehow guarantee that one of them happens first. The first question here would be but why?. And the second question is whether we trust users to for sure know the ordering that things are opened. On the other hand, it doesn't seem that hard to supply a description every time it's opened. I mean you just define it in one places within your script and use that. Or, better yet, just save the database to a variable and call open once early on in initialization. That'll make things less async anyway. Am I missing something here? I have actually been thinking that it's likely fairly common to be opening a database in several different locations and know which ones should always be reopening an existing database. I don't have any data on this though. Neither do I. Well, if we make it optional based on the assumption this is true, maybe we could spec it such that opening a database for the first time with no description is an error? Or we just remove description all together if it's not going to be dependable? Thinking more about it, do we really want this string to be displayed to the user? What happens if the browser is using one locale and the string is in another? To me, the description is something internal to the application, not something intended for the end-user. I think we should remove it altogether if we don't
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Thu, Aug 12, 2010 at 3:41 AM, Jeremy Orlow jor...@chromium.org wrote: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349 One quesiton though: if they pass in null or undefined, do we want to interpret this as the argument not being passed in or simply let them convert to undefined and null (which is the default behavior in WebIDL, I believe). I feel somewhat strongly we should do the former. Especially since the latter would make it impossible to add additional parameters to .open() in the future. I don't understand why it would make it impossible to add optional parameters in the future. Wouldn't it be a matter of people writing indexeddb.open(mydatabase, , SOME_OTHER_PARAM); vs. indexeddb.open(mydatabase, null, SOME_OTHER_PARAM); / Jonas
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Thu, Aug 12, 2010 at 11:55 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Aug 12, 2010 at 3:41 AM, Jeremy Orlow jor...@chromium.org wrote: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349 One quesiton though: if they pass in null or undefined, do we want to interpret this as the argument not being passed in or simply let them convert to undefined and null (which is the default behavior in WebIDL, I believe). I feel somewhat strongly we should do the former. Especially since the latter would make it impossible to add additional parameters to .open() in the future. I don't understand why it would make it impossible to add optional parameters in the future. Wouldn't it be a matter of people writing indexeddb.open(mydatabase, , SOME_OTHER_PARAM); vs. indexeddb.open(mydatabase, null, SOME_OTHER_PARAM); So is assumed to mean don't update? My assumption was that meant empty description. It seems silly to make someone replace the description with a space (or something like that) if they truly want to zero it out. And it seems silly to ever make your description be null. So it seemed natural to make null and/or undefined be such a signal. J
RE: [IndexedDB] question about description argument of IDBFactory::open()
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Jeremy Orlow
Sent: Thursday, August 12, 2010 3:59 AM
On Thu, Aug 12, 2010 at 11:55 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 12, 2010 at 3:41 AM, Jeremy Orlow jor...@chromium.org wrote:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349
One quesiton though: if they pass in null or undefined, do we want to
interpret this as the argument not being passed in or simply let them
convert to undefined and null (which is the default behavior in WebIDL,
I believe). I feel somewhat strongly we should do the former. Especially
since the latter would make it impossible to add additional parameters to
.open() in the future.
I don't understand why it would make it impossible to add optional
parameters in the future. Wouldn't it be a matter of people writing
indexeddb.open(mydatabase, , SOME_OTHER_PARAM);
vs.
indexeddb.open(mydatabase, null, SOME_OTHER_PARAM);
So is assumed to mean don't update? My assumption was that meant
empty description.
It seems silly to make someone replace the description with a space (or
something like that) if they truly want to zero it out. And it seems silly
to ever make your description be null. So it seemed natural to make
null and/or undefined be such a signal.
Given that open() is one of those functions that are likely to grow in
parameters over time, I wonder if we should consider taking an object as the
second argument with names/values(e.g. open(mydatabase, { description: foo
}); ). That would allow us to keep the minimum specification small and easily
add more parameters later without resulting un hard to read code that has a
bunch of undefined in arguments. The only thing I'm not sure is if there is
precedent of doing this in one of the standard APIs.
Thanks
-pablo
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Thu, Aug 12, 2010 at 6:28 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Jeremy Orlow
Sent: Thursday, August 12, 2010 3:59 AM
On Thu, Aug 12, 2010 at 11:55 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 12, 2010 at 3:41 AM, Jeremy Orlow jor...@chromium.org wrote:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349
One quesiton though: if they pass in null or undefined, do we want to
interpret this as the argument not being passed in or simply let them
convert to undefined and null (which is the default behavior in
WebIDL,
I believe). I feel somewhat strongly we should do the former. Especially
since the latter would make it impossible to add additional parameters to
.open() in the future.
I don't understand why it would make it impossible to add optional
parameters in the future. Wouldn't it be a matter of people writing
indexeddb.open(mydatabase, , SOME_OTHER_PARAM);
vs.
indexeddb.open(mydatabase, null, SOME_OTHER_PARAM);
So is assumed to mean don't update? My assumption was that meant
empty description.
It seems silly to make someone replace the description with a space (or
something like that) if they truly want to zero it out. And it seems silly
to ever make your description be null. So it seemed natural to make
null and/or undefined be such a signal.
Given that open() is one of those functions that are likely to grow in
parameters over time, I wonder if we should consider taking an object as the
second argument with names/values(e.g. open(mydatabase, { description:
foo }); ). That would allow us to keep the minimum specification small and
easily add more parameters later without resulting un hard to read code that
has a bunch of undefined in arguments.
This is fine with me.
The only thing I'm not sure is if there is precedent of doing this in one of
the standard APIs.
There is: http://dev.w3.org/geo/api/spec-source.html#position_interface
Thanks,
Andei
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Thu, Aug 12, 2010 at 6:54 PM, Andrei Popescu andr...@google.com wrote:
On Thu, Aug 12, 2010 at 6:28 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org]
On Behalf Of Jeremy Orlow
Sent: Thursday, August 12, 2010 3:59 AM
On Thu, Aug 12, 2010 at 11:55 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 12, 2010 at 3:41 AM, Jeremy Orlow jor...@chromium.org wrote:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349
One quesiton though: if they pass in null or undefined, do we want to
interpret this as the argument not being passed in or simply let them
convert to undefined and null (which is the default behavior in
WebIDL,
I believe). I feel somewhat strongly we should do the former.
Especially
since the latter would make it impossible to add additional parameters to
.open() in the future.
I don't understand why it would make it impossible to add optional
parameters in the future. Wouldn't it be a matter of people writing
indexeddb.open(mydatabase, , SOME_OTHER_PARAM);
vs.
indexeddb.open(mydatabase, null, SOME_OTHER_PARAM);
So is assumed to mean don't update? My assumption was that meant
empty description.
It seems silly to make someone replace the description with a space (or
something like that) if they truly want to zero it out. And it seems
silly to ever make your description be null. So it seemed natural to
make null and/or undefined be such a signal.
Given that open() is one of those functions that are likely to grow in
parameters over time, I wonder if we should consider taking an object as the
second argument with names/values(e.g. open(mydatabase, { description:
foo }); ). That would allow us to keep the minimum specification small and
easily add more parameters later without resulting un hard to read code that
has a bunch of undefined in arguments.
This is fine with me.
The only thing I'm not sure is if there is precedent of doing this in one of
the standard APIs.
There is: http://dev.w3.org/geo/api/spec-source.html#position_interface
Sorry, I meant PositionOptions:
http://dev.w3.org/geo/api/spec-source.html#position-options
Andrei
Re: [IndexedDB] question about description argument of IDBFactory::open()
That sounds great to me.
On Thu, Aug 12, 2010 at 10:55 AM, Andrei Popescu andr...@google.com wrote:
On Thu, Aug 12, 2010 at 6:54 PM, Andrei Popescu andr...@google.com
wrote:
On Thu, Aug 12, 2010 at 6:28 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:
From: public-webapps-requ...@w3.org [mailto:
public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow
Sent: Thursday, August 12, 2010 3:59 AM
On Thu, Aug 12, 2010 at 11:55 AM, Jonas Sicking jo...@sicking.cc
wrote:
On Thu, Aug 12, 2010 at 3:41 AM, Jeremy Orlow jor...@chromium.org
wrote:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10349
One quesiton though: if they pass in null or undefined, do we want
to
interpret this as the argument not being passed in or simply let
them
convert to undefined and null (which is the default behavior in
WebIDL,
I believe). I feel somewhat strongly we should do the former.
Especially
since the latter would make it impossible to add additional
parameters to
.open() in the future.
I don't understand why it would make it impossible to add optional
parameters in the future. Wouldn't it be a matter of people writing
indexeddb.open(mydatabase, , SOME_OTHER_PARAM);
vs.
indexeddb.open(mydatabase, null, SOME_OTHER_PARAM);
So is assumed to mean don't update? My assumption was that
meant empty description.
It seems silly to make someone replace the description with a space
(or something like that) if they truly want to zero it out. And it seems
silly to ever make your description be null. So it seemed natural to
make null and/or undefined be such a signal.
Given that open() is one of those functions that are likely to grow in
parameters over time, I wonder if we should consider taking an object as the
second argument with names/values(e.g. open(mydatabase, { description:
foo }); ). That would allow us to keep the minimum specification small and
easily add more parameters later without resulting un hard to read code that
has a bunch of undefined in arguments.
This is fine with me.
The only thing I'm not sure is if there is precedent of doing this in
one of the standard APIs.
There is: http://dev.w3.org/geo/api/spec-source.html#position_interface
Sorry, I meant PositionOptions:
http://dev.w3.org/geo/api/spec-source.html#position-options
Andrei
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Thu, Aug 12, 2010 at 11:44 AM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Aug 12, 2010 at 10:55 AM, Andrei Popescu andr...@google.com wrote:
Given that open() is one of those functions that are likely to grow in
parameters over time, I wonder if we should consider taking an object as the
second argument with names/values(e.g. open(mydatabase, { description:
foo }); ). That would allow us to keep the minimum specification small and
easily add more parameters later without resulting un hard to read code that
has a bunch of undefined in arguments.
The only thing I'm not sure is if there is precedent of doing this in
one of the standard APIs.
That sounds great to me.
Thank god, maybe we can *finally* make this a pattern in the web
platform. Javascript's lack of keyword parameters is already a pain;
the inexplicable resistance to adding this common hack around that
into the web platform has pained me every time.
~TJ
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Wed, Aug 11, 2010 at 11:50 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 10, 2010 at 12:26 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 10, 2010 at 11:30 AM, Andrei Popescu andr...@google.com wrote: On Mon, Aug 9, 2010 at 11:36 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:31 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 9, 2010 at 3:24 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:15 PM, Andrei Popescu andr...@google.com wrote: On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow jor...@chromium.org wrote: I'm pretty sure opening a database with a different description is actually already specified: the new one takes precedent. Take a look at the algorithm for database opening; I'm pretty sure it's there. When talking to Andrei earlier tonight I thought we'd probably want to make it optional, but now I'm thinking maybe we shouldn't. You're right, Shawn, that the description can be useful for many reasons. And although it seems redundant for a developer to pass in the description every time, I actually can't think of any reason why a developer wouldn't want to. Actually, I think it's pretty inconvenient to have to specify a description every time, especially since I am not sure developers would want to change the description very often. I think we should allow a null string for future connections as Shawn suggested. How do developers distinguish between when they're opening a database for the first time or not? Normally they'd look at the version, but that's not available until _after_ you've supplied the description (and presumably some UAs might have asked the user if it's OK or something like that). If the spec has a way to enumerate databases (something we've talked about doing) then it's possible that the developer could decide whether or not to pass in a version string that way. But why would they do this? So the only possible reason I could see for someone doing this is if they open a database in several places in one page and they can somehow guarantee that one of them happens first. The first question here would be but why?. And the second question is whether we trust users to for sure know the ordering that things are opened. On the other hand, it doesn't seem that hard to supply a description every time it's opened. I mean you just define it in one places within your script and use that. Or, better yet, just save the database to a variable and call open once early on in initialization. That'll make things less async anyway. Am I missing something here? I have actually been thinking that it's likely fairly common to be opening a database in several different locations and know which ones should always be reopening an existing database. I don't have any data on this though. Neither do I. Well, if we make it optional based on the assumption this is true, maybe we could spec it such that opening a database for the first time with no description is an error? Or we just remove description all together if it's not going to be dependable? Thinking more about it, do we really want this string to be displayed to the user? What happens if the browser is using one locale and the string is in another? To me, the description is something internal to the application, not something intended for the end-user. I think we should remove it altogether if we don't have a good use case for it. Also there are security concerns. For example, it'd be hard to use the description in a useful way without trusting what it says. Which isn't always possible. Also, thinking about it, I'm not sure I see much of a use case for users managing (for example deleting) individual databases. (For many of the same reasons as why we wouldn't let users delete individual ObjectStores.) The main problem is that there's a risk that apps will break if one database is deleted and another isn't. Some teams at Google have suggested that we allow databases to be grouped such that one can't be deleted by the user without deleting the others in the group. Personally I think the easier way to handle this is just not allow users to manage databases at a finer grained level than per origin. So, beyond these reasons, why else do we want the developer to supply a description? What are the use cases? If we decide to leave it in, I'm now leaning towards adding it to setVersion. There's no way to add any data (i.e. use any space) until you call setVersion since that's necessary to create objectStores. So even if the UA wanted to display this while asking the user about doling out space (despite my security concerns) or the UA wanted to display this in some dialog for users
Re: [IndexedDB] question about description argument of IDBFactory::open()
I am fine with removing it. -Ben
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Wed, Aug 11, 2010 at 8:45 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 11, 2010 at 11:50 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 10, 2010 at 12:26 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 10, 2010 at 11:30 AM, Andrei Popescu andr...@google.com wrote: On Mon, Aug 9, 2010 at 11:36 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:31 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 9, 2010 at 3:24 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:15 PM, Andrei Popescu andr...@google.com wrote: On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow jor...@chromium.org wrote: I'm pretty sure opening a database with a different description is actually already specified: the new one takes precedent. Take a look at the algorithm for database opening; I'm pretty sure it's there. When talking to Andrei earlier tonight I thought we'd probably want to make it optional, but now I'm thinking maybe we shouldn't. You're right, Shawn, that the description can be useful for many reasons. And although it seems redundant for a developer to pass in the description every time, I actually can't think of any reason why a developer wouldn't want to. Actually, I think it's pretty inconvenient to have to specify a description every time, especially since I am not sure developers would want to change the description very often. I think we should allow a null string for future connections as Shawn suggested. How do developers distinguish between when they're opening a database for the first time or not? Normally they'd look at the version, but that's not available until _after_ you've supplied the description (and presumably some UAs might have asked the user if it's OK or something like that). If the spec has a way to enumerate databases (something we've talked about doing) then it's possible that the developer could decide whether or not to pass in a version string that way. But why would they do this? So the only possible reason I could see for someone doing this is if they open a database in several places in one page and they can somehow guarantee that one of them happens first. The first question here would be but why?. And the second question is whether we trust users to for sure know the ordering that things are opened. On the other hand, it doesn't seem that hard to supply a description every time it's opened. I mean you just define it in one places within your script and use that. Or, better yet, just save the database to a variable and call open once early on in initialization. That'll make things less async anyway. Am I missing something here? I have actually been thinking that it's likely fairly common to be opening a database in several different locations and know which ones should always be reopening an existing database. I don't have any data on this though. Neither do I. Well, if we make it optional based on the assumption this is true, maybe we could spec it such that opening a database for the first time with no description is an error? Or we just remove description all together if it's not going to be dependable? Thinking more about it, do we really want this string to be displayed to the user? What happens if the browser is using one locale and the string is in another? To me, the description is something internal to the application, not something intended for the end-user. I think we should remove it altogether if we don't have a good use case for it. Also there are security concerns. For example, it'd be hard to use the description in a useful way without trusting what it says. Which isn't always possible. Also, thinking about it, I'm not sure I see much of a use case for users managing (for example deleting) individual databases. (For many of the same reasons as why we wouldn't let users delete individual ObjectStores.) The main problem is that there's a risk that apps will break if one database is deleted and another isn't. Some teams at Google have suggested that we allow databases to be grouped such that one can't be deleted by the user without deleting the others in the group. Personally I think the easier way to handle this is just not allow users to manage databases at a finer grained level than per origin. So, beyond these reasons, why else do we want the developer to supply a description? What are the use cases? If we decide to leave it in, I'm now leaning towards adding it to setVersion. There's no way to add any data (i.e. use any space) until you call setVersion since that's necessary to create objectStores. So even if the UA wanted to display this while asking the user about doling out space (despite my
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Wed, Aug 11, 2010 at 1:30 PM, Andrei Popescu andr...@google.com wrote: On Wed, Aug 11, 2010 at 8:45 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 11, 2010 at 11:50 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 10, 2010 at 12:26 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 10, 2010 at 11:30 AM, Andrei Popescu andr...@google.com wrote: On Mon, Aug 9, 2010 at 11:36 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:31 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 9, 2010 at 3:24 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:15 PM, Andrei Popescu andr...@google.com wrote: On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow jor...@chromium.org wrote: I'm pretty sure opening a database with a different description is actually already specified: the new one takes precedent. Take a look at the algorithm for database opening; I'm pretty sure it's there. When talking to Andrei earlier tonight I thought we'd probably want to make it optional, but now I'm thinking maybe we shouldn't. You're right, Shawn, that the description can be useful for many reasons. And although it seems redundant for a developer to pass in the description every time, I actually can't think of any reason why a developer wouldn't want to. Actually, I think it's pretty inconvenient to have to specify a description every time, especially since I am not sure developers would want to change the description very often. I think we should allow a null string for future connections as Shawn suggested. How do developers distinguish between when they're opening a database for the first time or not? Normally they'd look at the version, but that's not available until _after_ you've supplied the description (and presumably some UAs might have asked the user if it's OK or something like that). If the spec has a way to enumerate databases (something we've talked about doing) then it's possible that the developer could decide whether or not to pass in a version string that way. But why would they do this? So the only possible reason I could see for someone doing this is if they open a database in several places in one page and they can somehow guarantee that one of them happens first. The first question here would be but why?. And the second question is whether we trust users to for sure know the ordering that things are opened. On the other hand, it doesn't seem that hard to supply a description every time it's opened. I mean you just define it in one places within your script and use that. Or, better yet, just save the database to a variable and call open once early on in initialization. That'll make things less async anyway. Am I missing something here? I have actually been thinking that it's likely fairly common to be opening a database in several different locations and know which ones should always be reopening an existing database. I don't have any data on this though. Neither do I. Well, if we make it optional based on the assumption this is true, maybe we could spec it such that opening a database for the first time with no description is an error? Or we just remove description all together if it's not going to be dependable? Thinking more about it, do we really want this string to be displayed to the user? What happens if the browser is using one locale and the string is in another? To me, the description is something internal to the application, not something intended for the end-user. I think we should remove it altogether if we don't have a good use case for it. Also there are security concerns. For example, it'd be hard to use the description in a useful way without trusting what it says. Which isn't always possible. Also, thinking about it, I'm not sure I see much of a use case for users managing (for example deleting) individual databases. (For many of the same reasons as why we wouldn't let users delete individual ObjectStores.) The main problem is that there's a risk that apps will break if one database is deleted and another isn't. Some teams at Google have suggested that we allow databases to be grouped such that one can't be deleted by the user without deleting the others in the group. Personally I think the easier way to handle this is just not allow users to manage databases at a finer grained level than per origin. So, beyond these reasons, why else do we want the developer to supply a description? What are the use cases? If we decide to leave it in, I'm now leaning towards adding it to setVersion. There's no way to add any data (i.e. use any space) until you call setVersion since that's necessary to create objectStores. So even if the UA wanted
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Wed, Aug 11, 2010 at 10:33 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 11, 2010 at 1:30 PM, Andrei Popescu andr...@google.com wrote: On Wed, Aug 11, 2010 at 8:45 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 11, 2010 at 11:50 AM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 10, 2010 at 12:26 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Aug 10, 2010 at 11:30 AM, Andrei Popescu andr...@google.com wrote: On Mon, Aug 9, 2010 at 11:36 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:31 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 9, 2010 at 3:24 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:15 PM, Andrei Popescu andr...@google.com wrote: On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow jor...@chromium.org wrote: I'm pretty sure opening a database with a different description is actually already specified: the new one takes precedent. Take a look at the algorithm for database opening; I'm pretty sure it's there. When talking to Andrei earlier tonight I thought we'd probably want to make it optional, but now I'm thinking maybe we shouldn't. You're right, Shawn, that the description can be useful for many reasons. And although it seems redundant for a developer to pass in the description every time, I actually can't think of any reason why a developer wouldn't want to. Actually, I think it's pretty inconvenient to have to specify a description every time, especially since I am not sure developers would want to change the description very often. I think we should allow a null string for future connections as Shawn suggested. How do developers distinguish between when they're opening a database for the first time or not? Normally they'd look at the version, but that's not available until _after_ you've supplied the description (and presumably some UAs might have asked the user if it's OK or something like that). If the spec has a way to enumerate databases (something we've talked about doing) then it's possible that the developer could decide whether or not to pass in a version string that way. But why would they do this? So the only possible reason I could see for someone doing this is if they open a database in several places in one page and they can somehow guarantee that one of them happens first. The first question here would be but why?. And the second question is whether we trust users to for sure know the ordering that things are opened. On the other hand, it doesn't seem that hard to supply a description every time it's opened. I mean you just define it in one places within your script and use that. Or, better yet, just save the database to a variable and call open once early on in initialization. That'll make things less async anyway. Am I missing something here? I have actually been thinking that it's likely fairly common to be opening a database in several different locations and know which ones should always be reopening an existing database. I don't have any data on this though. Neither do I. Well, if we make it optional based on the assumption this is true, maybe we could spec it such that opening a database for the first time with no description is an error? Or we just remove description all together if it's not going to be dependable? Thinking more about it, do we really want this string to be displayed to the user? What happens if the browser is using one locale and the string is in another? To me, the description is something internal to the application, not something intended for the end-user. I think we should remove it altogether if we don't have a good use case for it. Also there are security concerns. For example, it'd be hard to use the description in a useful way without trusting what it says. Which isn't always possible. Also, thinking about it, I'm not sure I see much of a use case for users managing (for example deleting) individual databases. (For many of the same reasons as why we wouldn't let users delete individual ObjectStores.) The main problem is that there's a risk that apps will break if one database is deleted and another isn't. Some teams at Google have suggested that we allow databases to be grouped such that one can't be deleted by the user without deleting the others in the group. Personally I think the easier way to handle this is just not allow users to manage databases at a finer grained level than per origin. So, beyond these reasons, why else do we want the developer to supply a description? What are the use cases? If we
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Mon, Aug 9, 2010 at 11:36 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:31 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 9, 2010 at 3:24 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 9, 2010 at 11:15 PM, Andrei Popescu andr...@google.com wrote: On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow jor...@chromium.org wrote: I'm pretty sure opening a database with a different description is actually already specified: the new one takes precedent. Take a look at the algorithm for database opening; I'm pretty sure it's there. When talking to Andrei earlier tonight I thought we'd probably want to make it optional, but now I'm thinking maybe we shouldn't. You're right, Shawn, that the description can be useful for many reasons. And although it seems redundant for a developer to pass in the description every time, I actually can't think of any reason why a developer wouldn't want to. Actually, I think it's pretty inconvenient to have to specify a description every time, especially since I am not sure developers would want to change the description very often. I think we should allow a null string for future connections as Shawn suggested. How do developers distinguish between when they're opening a database for the first time or not? Normally they'd look at the version, but that's not available until _after_ you've supplied the description (and presumably some UAs might have asked the user if it's OK or something like that). If the spec has a way to enumerate databases (something we've talked about doing) then it's possible that the developer could decide whether or not to pass in a version string that way. But why would they do this? So the only possible reason I could see for someone doing this is if they open a database in several places in one page and they can somehow guarantee that one of them happens first. The first question here would be but why?. And the second question is whether we trust users to for sure know the ordering that things are opened. On the other hand, it doesn't seem that hard to supply a description every time it's opened. I mean you just define it in one places within your script and use that. Or, better yet, just save the database to a variable and call open once early on in initialization. That'll make things less async anyway. Am I missing something here? I have actually been thinking that it's likely fairly common to be opening a database in several different locations and know which ones should always be reopening an existing database. I don't have any data on this though. Neither do I. Well, if we make it optional based on the assumption this is true, maybe we could spec it such that opening a database for the first time with no description is an error? Or we just remove description all together if it's not going to be dependable? Thinking more about it, do we really want this string to be displayed to the user? What happens if the browser is using one locale and the string is in another? To me, the description is something internal to the application, not something intended for the end-user. I think we should remove it altogether if we don't have a good use case for it. Thanks, Andrei
[IndexedDB] question about description argument of IDBFactory::open()
Hi, While implementing IDBFactory::open(), we thought that the description argument is optional but we were surprised to find out it's actually mandatory. Is there any reason not to make this argument optional? And, assuming it is optional, should the default value be the empty string? Also, how should the null and undefined values be treated? My suggestion would be to treat them as if the argument wasn't specified, so the description of the database would not change. Thanks, Andrei
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Mon, Aug 9, 2010 at 1:13 PM, Andrei Popescu andr...@google.com wrote: Hi, While implementing IDBFactory::open(), we thought that the description argument is optional but we were surprised to find out it's actually mandatory. Is there any reason not to make this argument optional? And, assuming it is optional, should the default value be the empty string? Also, how should the null and undefined values be treated? My suggestion would be to treat them as if the argument wasn't specified, so the description of the database would not change. I agree optional makes sense, defaulting to empty string. null and undefined should IMHO be defined by webidl. I forget what the syntax is, but I believe it's possible to enforce that the passed in value is converted to a real string before passed to the actual function. / Jonas
Re: [IndexedDB] question about description argument of IDBFactory::open()
On 8/9/2010 1:13 PM, Andrei Popescu wrote: While implementing IDBFactory::open(), we thought that the description argument is optional but we were surprised to find out it's actually mandatory. Is there any reason not to make this argument optional? And, assuming it is optional, should the default value be the empty string? Also, how should the null and undefined values be treated? My suggestion would be to treat them as if the argument wasn't specified, so the description of the database would not change. I think we want something there, because that is likely what the user agent is going to tell the user when it has to ask for space (if the user agent limits) or display if the user wants to see what a site is storing locally. I think we should probably enforce a non-null string too because of this, although a null string for future connections meaning do not change seem fine to me. I started a bug [1] a while back about what to do if it changes, but it went nowhere. Cheers, Shawn [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9562 smime.p7s Description: S/MIME Cryptographic Signature
Re: [IndexedDB] question about description argument of IDBFactory::open()
I'm pretty sure opening a database with a different description is actually already specified: the new one takes precedent. Take a look at the algorithm for database opening; I'm pretty sure it's there. When talking to Andrei earlier tonight I thought we'd probably want to make it optional, but now I'm thinking maybe we shouldn't. You're right, Shawn, that the description can be useful for many reasons. And although it seems redundant for a developer to pass in the description every time, I actually can't think of any reason why a developer wouldn't want to. So, just to make sure we always have a description handy, it seems like maybe we should keep it non-optional. As for Jonas' comment about IDL: I believe the default is for null to turn into null and undefined to turn into undefined, but IDL has ways of overriding the behavior. To me, null and undefined as database descriptions are pretty useless, but I don't see how we can spec that descriptions must be useful. Off the top of my head, it seems as though we could get away with making all strings in the IndexedDB treat null/undefined as an empty string, but would this be consistent with other specs in a predictable way? I'm not sure. But I think consistency/predictability for the user is the most important consideration. J On Mon, Aug 9, 2010 at 9:42 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 8/9/2010 1:13 PM, Andrei Popescu wrote: While implementing IDBFactory::open(), we thought that the description argument is optional but we were surprised to find out it's actually mandatory. Is there any reason not to make this argument optional? And, assuming it is optional, should the default value be the empty string? Also, how should the null and undefined values be treated? My suggestion would be to treat them as if the argument wasn't specified, so the description of the database would not change. I think we want something there, because that is likely what the user agent is going to tell the user when it has to ask for space (if the user agent limits) or display if the user wants to see what a site is storing locally. I think we should probably enforce a non-null string too because of this, although a null string for future connections meaning do not change seem fine to me. I started a bug [1] a while back about what to do if it changes, but it went nowhere. Cheers, Shawn [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9562
Re: [IndexedDB] question about description argument of IDBFactory::open()
On Mon, Aug 9, 2010 at 9:57 PM, Jeremy Orlow jor...@chromium.org wrote: I'm pretty sure opening a database with a different description is actually already specified: the new one takes precedent. Take a look at the algorithm for database opening; I'm pretty sure it's there. When talking to Andrei earlier tonight I thought we'd probably want to make it optional, but now I'm thinking maybe we shouldn't. You're right, Shawn, that the description can be useful for many reasons. And although it seems redundant for a developer to pass in the description every time, I actually can't think of any reason why a developer wouldn't want to. Actually, I think it's pretty inconvenient to have to specify a description every time, especially since I am not sure developers would want to change the description very often. I think we should allow a null string for future connections as Shawn suggested. Thanks, Andrei
