RE: Seeking pre-LCWD comments for Indexed Database API; deadline February 2

[Pablo Castro]

A few comments inline marked with [PC].

From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On 
Behalf Of Nikunj Mehta
Sent: Sunday, January 31, 2010 11:37 PM
To: Kris Zyp
Cc: Arthur Barstow; public-webapps
Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline 
February 2


On Jan 27, 2010, at 1:46 PM, Kris Zyp wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A few comments I've been meaning to suggest:

* count on KeyRange - Previously I had asked if there would be a way
to get a count of the number of objects within a given key range. The
addition of the KeyRange interface seems to be a step towards that,
but the cursor generated with a KeyRange still only provides a "count"
property that returns "the total number of objects that share the
current key". There is still no way to determine how many objects are
within a range. Was the intent to make "count" return the number of
objects in a KeyRange and the wording is just not up to date?
Otherwise could we add such a count property (countForRange maybe, or
have a count and countForKey, I think Pablo suggested something like
that).

I agree with the concept. I have doubts about implementation success. However, 
I will include this in the editor's draft.

[PC] I agree with Nikunj, I suspect that a implementations will have to just 
compute the count, as it's unlikely that updating intermediate nodes in the 
tree for each update would  be desired (to try to maintain extra information 
for fast range size computation). At that point it's almost the same as user 
code iterating over the range (modulo the Javascript interface overhead). I'm 
also not sure how often you'd use this, as it would only work on simple 
conditions (no composite expressions, no functions in expressions)  that happen 
to have an index.

* Use promises for async interfaces - In server side JavaScript, most
projects are moving towards using promises for asynchronous interfaces
instead of trying to define the specific callback parameters for each
interface. I believe the advantages of using promises over callbacks
are pretty well understood in terms of decoupling async semantics from
interface definitions, and improving encapsulation of concerns. For
the indexed database API this would mean that sync and async
interfaces could essentially look the same except sync would return
completed values and async would return promises. I realize that
defining a promise interface would have implications beyond the
indexed database API, as the goal of promises is to provide a
consistent interface for asynchronous interaction across components,
but perhaps this would be a good time for the W3C to define such an
API. It seems like the indexed database API would be a perfect
interface to leverage promises. If you are interested in proposal,
there is one from CommonJS here [1] (the get() and call() wouldn't
apply here). With this interface, a promise.then(callback,
errorHandler) function is the only function a promise would need to
provide.

Thanks for the pointer. I will look in to this as even Pablo had related 
requirements.


[1] http://wiki.commonjs.org/wiki/Promises

and a comment on this:
On 1/26/2010 1:47 PM, Pablo Castro wrote:
> 11. API Names
>
 > a.   "transaction" is really non-intuitive (particularly given
> the existence of currentTransaction in the same class).
> "beginTransaction" would capture semantics more accurately. b.
> ObjectStoreSync.delete: delete is a Javascript keyword, can we use
> "remove" instead?
I'd prefer to keep both of these as is. Since commit and abort are
part of the transaction interface, using transaction() to denote the
transaction creator seems brief and appropriate. As far as
ObjectStoreSync.delete, most JS engines have or should be contextually
reserving "delete". I certainly prefer delete in preserving the
familiarity of REST terminology.
[PC] I understand the term familiarity aspect, but this seems to be something 
that would just cause trouble. From a quick check with the browsers I had at 
hand, both IE8 and Safari 4 reject scripts where you try to add a method called 
"delete" to an object's prototype. Natively-implemented objects may be able to 
work-around this but I see no reason to push it. remove()  is probably equally 
intuitive. Note that the method "continue" on async cursors are likely to have 
the same issue as continue is also a Javascript keyword.


Thanks,

- --
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/

iEYEARECAAYFAktgtCkACgkQ9VpNnHc4zAwlkgCgti99/iJMi1QqDJYsMgxj9hC3
X0cAnj0J0xzqIQa8abaBQ8qxCMe/7/sU
=W6Jx
-END PGP SIGNATURE-

-pablo

Re: Feedback on WebSocket API, Editor's Draft 13 November 2009.

[Ian Hickson]

On Mon, 1 Feb 2010, Sebastian Andersson wrote:
> On Mon, Feb 1, 2010 at 10:47, Ian Hickson  wrote:
> > On Sun, 31 Jan 2010, Sebastian Andersson wrote:
> >> On Sat, Jan 30, 2010 at 10:31, Ian Hickson  wrote:
> >> > Right now, today, if I were to expose a WebSocket service on my
> >> > Dreamhost shared server, I could do so without any trouble. If we used
> >> > a scheme such as the one described above using a policy file, anyone
> >> > else also hosting their site on the same server could grant access to
> >> > my server to their scripts on their page. Whether this is a technical
> >> > or administrative issue, it's an issue we have to handle today.
> >>
> >> If you only allow the policy file from being read from a single port
> >
> > How would we do that?
> 
> I think it is pretty obvious. Do it like Silverlight! The policy file
> is downloaded from port 943. If it is not available there, you have no
> right to connect to this IP number.

So anyone who's behind a firewall that blocks all but ports 80 and 443 is 
blocked from using Web Sockets? That's a pretty serious problem.


> How do you protect your Web Socket service from another user on your 
> shared host? They can publish flash clients and java applets that 
> connects to your server and present any origin they want.

Like I said, Flash has all kinds of security problems.

(The risk in this case is minimal, though, since it wouldn't send ambient 
authority headers -- like Cookies -- with the request, which are the main 
problem in a shared hosting environment.)


> >> -- Instead of just having a few correct implementations in the 
> >> clients (that already have code for origin handling and whose 
> >> designers hopefully are aware of the problems), each server will have 
> >> to have it with associated risks of errors. A huge potential for new 
> >> security problems. Will of course be cheaper and less risky when 
> >> libraries are available for most languages, but still many more 
> >> implementations.
> >
> > I don't understand. Why would the servers have it? It's the client 
> > that enforces the security policy.
> 
> From section 5.1 in the protocol specification:
> "Servers that are not intended to process input from any Web page but
>only for certain sites should verify the "Origin" header is an origin
>they expect, and should only respond with the corresponding
>"WebSocket-Origin" if it is an accepted origin"
> 
> I think that covers a large proportion of the servers and I think that 
> most projects would want to implement support for it just to allow 
> different server deployment scenarios.

I would imagine most would only accept connections from _one_ site, and 
they can just send back the appropriate WebSocket-Origin without checking 
what the client has sent.


> > Fundamentally, raw sockets plus a policy file is a completely 
> > different approach than Web Sockets. I would recommend developing a 
> > second proposal separate from the Web Sockets spec, and approaching 
> > browser vendors to see if they prefer it.
> 
> Ok. Perhaps I'm pessimistic here, but I fear that one important browser 
> vendor would prefer that raw sockets were not added so their own 
> competing technology remains a better choice and if the Web Socket 
> protocol is part of html 5, it is easier for them to just say no. I hope 
> I'm wrong though.

Well if that's the case, we wouldn't be able to change Web Socket either.


For the rest of your points, we're basically just disagreeing with each 
other's priorities, not with the facts. So I don't think we can make much 
progress. Your ideas are not wrong, they're just solving a different set 
of problems, or a set of problems with different priorities, than what Web 
Socket is setting out to solve. I really _would_ recommend approaching 
browser vendors and seeing if they would prefer a different approach, or 
another approach in addition to this one, and then if they do, editing a 
spec for that new approach.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [WebSQLDatabase] Minor change to spec?

[Dumitru Daniliuc]

Thanks for clarifying this, Ian.

Dumi


On Mon, Feb 1, 2010 at 4:53 PM, Ian Hickson  wrote:

> On Mon, 1 Feb 2010, Dumitru Daniliuc wrote:
> >
> > In section 4.3.2, point 6, the "In case of error..." paragraph says:
> >
> > 2. If the error callback returns false, then move on to the next
> statement,
> > if any, or onto the next overall step otherwise.
> > 3. Otherwise, the error callback did not return false, or there was no
> error
> > callback. Jump to the last step in the overall steps.
> >
> > I'm proposing the following change (the wording could be different, of
> > course):
> >
> > 2. If the error callback returns false *and the transaction is not in an
> > unrecoverable state*, then move on to the next statement, if any, or onto
> > the next overall step otherwise.
> > 3. Otherwise, if the error callback did not return false, or there was no
> > error callback, *or the transaction is an unrecoverable state*, jump to
> the
> > last step in the overall steps.
> >
> > This request is motivated by
> http://www.sqlite.org/c3ref/get_autocommit.html:
> > "If certain kinds of errors occur on a statement within a multi-statement
> > transaction (errors including
> > SQLITE_FULL,
> > SQLITE_IOERR ,
> > SQLITE_NOMEM,
> > SQLITE_BUSY , and
> > SQLITE_INTERRUPT)
> > then the transaction might be rolled back automatically." If such an
> error
> > occurs, we cannot move on to the next statement as currently requested by
> > the spec.
>
> These fall under the general "User agents may impose
> implementation-specific limits on otherwise unconstrained inputs, e.g. to
> prevent denial of service attacks, to guard against running out of memory,
> or to work around platform-specific limitations." rule, under which you
> can basically do whatever you need to do to handle unexpected errors.
>
> If I edit the spec again, I'll make this more clear.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [WebSQLDatabase] Minor change to spec?

[Ian Hickson]

On Mon, 1 Feb 2010, Dumitru Daniliuc wrote:
>
> In section 4.3.2, point 6, the "In case of error..." paragraph says:
> 
> 2. If the error callback returns false, then move on to the next statement,
> if any, or onto the next overall step otherwise.
> 3. Otherwise, the error callback did not return false, or there was no error
> callback. Jump to the last step in the overall steps.
> 
> I'm proposing the following change (the wording could be different, of
> course):
> 
> 2. If the error callback returns false *and the transaction is not in an
> unrecoverable state*, then move on to the next statement, if any, or onto
> the next overall step otherwise.
> 3. Otherwise, if the error callback did not return false, or there was no
> error callback, *or the transaction is an unrecoverable state*, jump to the
> last step in the overall steps.
> 
> This request is motivated by http://www.sqlite.org/c3ref/get_autocommit.html:
> "If certain kinds of errors occur on a statement within a multi-statement
> transaction (errors including
> SQLITE_FULL,
> SQLITE_IOERR ,
> SQLITE_NOMEM,
> SQLITE_BUSY , and
> SQLITE_INTERRUPT)
> then the transaction might be rolled back automatically." If such an error
> occurs, we cannot move on to the next statement as currently requested by
> the spec.

These fall under the general "User agents may impose 
implementation-specific limits on otherwise unconstrained inputs, e.g. to 
prevent denial of service attacks, to guard against running out of memory, 
or to work around platform-specific limitations." rule, under which you 
can basically do whatever you need to do to handle unexpected errors.

If I edit the spec again, I'll make this more clear.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[WebSQLDatabase] Minor change to spec?

[Dumitru Daniliuc]

In section 4.3.2, point 6, the "In case of error..." paragraph says:

2. If the error callback returns false, then move on to the next statement,
if any, or onto the next overall step otherwise.
3. Otherwise, the error callback did not return false, or there was no error
callback. Jump to the last step in the overall steps.

I'm proposing the following change (the wording could be different, of
course):

2. If the error callback returns false *and the transaction is not in an
unrecoverable state*, then move on to the next statement, if any, or onto
the next overall step otherwise.
3. Otherwise, if the error callback did not return false, or there was no
error callback, *or the transaction is an unrecoverable state*, jump to the
last step in the overall steps.

This request is motivated by http://www.sqlite.org/c3ref/get_autocommit.html:
"If certain kinds of errors occur on a statement within a multi-statement
transaction (errors including
SQLITE_FULL,
SQLITE_IOERR ,
SQLITE_NOMEM,
SQLITE_BUSY , and
SQLITE_INTERRUPT)
then the transaction might be rolled back automatically." If such an error
occurs, we cannot move on to the next statement as currently requested by
the spec.

Thanks,
Dumi

Re: File API: Blob and underlying file changes.

[Jonas Sicking]

On Mon, Feb 1, 2010 at 12:27 PM, Dmitry Titov  wrote:
> Basically, it's app-specific choice. It appears that the
> following implementation goes along with the current edition of the spec but
> also provides the ability to detect the file change:
> 1. File derives from Blob, so there is a File.size that performs synchronous
> file I/O. Not ideal, but easy to use and compatible with current forms
> upload.
> 2. File.slice() also does a synchronous IO and captures the current size and
> modification time of the underlying file - and caches it in the resulting
> Blob.

Note that the synch IO is not required by the spec. You can just cache
the filesize when the File object is created, which always happens
asynchronously. Then used that cached value through all calls to
File.size and Blob.slice().

> 4. In xhr.send() and FileReader, if the UA discovers that the underlying
> file is changed, it behaves just like when other file errors are discovered
> - returning 'error' progress event and setting FileReader.error attribute
> for example. We might need another FileError code for that if existing ones
> do not feel adequate.

This is definitely an interesting idea, possibly even something that
we should standardize. I don't really feel strongly either way, though
I am curious about platform support if the file lives in NFS or samba
or some such.

> One obvious difficulty here is the synchronous file IO on File.size and
> File.slice(). Trying to eliminate it requires some complexity in API that is
> not obviously better.

See above.

/ Jonas

Re: File API: Blob and underlying file changes.

[Dmitry Titov]

Going a bit back to current spec and changing underlying files - here is an
update on our thinking (and current implementation plan). We played with
File/Blob ideas a little more and talked with some of our app developers. In
regard to a problem of changing file, most folks feel the Blob is best to be
though of as a 'snapshot of a byte range' with a delayed promise to deliver
the actual bytes in that range from the underlying data storage. It is a
'delayed promise' because all the actual 'reading' methods are async.
Basically, in terms of implementation, the Blob is not a 'container of
bytes' but rather a 'reference' to the byte range.

As such, the async read operations later may fail, for many reasons - the
file can be deleted, renamed, modified, etc. It seems developers sometimes
want to be oblivious to those problems, but in other scenarios they want to
process them. Basically, it's app-specific choice. It appears that the
following implementation goes along with the current edition of the spec but
also provides the ability to detect the file change:

1. File derives from Blob, so there is a File.size that performs synchronous
file I/O. Not ideal, but easy to use and compatible with current forms
upload.
2. File.slice() also does a synchronous IO and captures the current size and
modification time of the underlying file - and caches it in the resulting
Blob.
3. Subsequent Blob.slice() and Blob.size calls do not do any file IO, but
merely operate on cached values. So the only Blob methods that do sync IO
are those on the File object. Subsequent slicing operates on the file
information captured from File and propagate it to derived Blobs.
4. In xhr.send() and FileReader, if the UA discovers that the underlying
file is changed, it behaves just like when other file errors are discovered
- returning 'error' progress event and setting FileReader.error attribute
for example. We might need another FileError code for that if existing ones
do not feel adequate.

This way, the folks who don't care about changing files could simply ignore
the error results - because they likely do not worry about other errors as
well (such as NOT_FOUND_ERR). At the same time, folks that worry about such
things, could simply process the errors already specified. It also doesn't
add new exceptions to the picture so no special code is needed in simple
cases.

One obvious difficulty here is the synchronous file IO on File.size and
File.slice(). Trying to eliminate it requires some complexity in API that is
not obviously better. It either leads to some strange APIs like a getSize()
with a callback that delivers the size, or/and breaks behavior of currently
implemented File (and most developer's expectations). In any case, an
attempt to completely avoid sync IO and preserve correctness seems to be
calling for a way more involved API. Considering that most uploaders which
slice the file and send it in pieces will likely do it in a worker thread,
sync IO in these places perhaps is a lesser evil then complicated (or dual)
API...

Thanks,
Dmitry

On Wed, Jan 27, 2010 at 4:40 AM, Juan Lanus  wrote:

> On Wed, Jan 27, 2010 at 01:16, Robert O'Callahan 
> wrote:
> > On Wed, Jan 27, 2010 at 5:38 AM, Juan Lanus 
> wrote:
> >>
> >> Quite right Bob. But still the lock is the way to go. At least as of
> >> today.
> >>
> >> HTML5 might be mainstream for the next 10 years, starting rather soon.
> >>
> >> In the meanwhile OSs will also evolve, in a way that we can't tell
> >> now. But if there are common issues, like this one, somebody will come
> >> up with a smart solution maybe soon.
> >> For example feeding an image of the file as of the instant it was
> >> opened (like relational databases do to provide stable queries) by
> >> keeping a temporary map to the original disk segments that comprised
> >> the file before it was changed.
> >> For example Apple is encouraging advisory locks
> >>
> >>
> http://developer.apple.com/mac/library/technotes/tn/tn2037.html#OSSolutions
> >> asking developers to design in an environment-aware mood.
> >
> > In my experience, almost no code uses advisory locking unless it is being
> > explicitly designed for some kind of concurrent usage, i.e., Apple's
> advice
> > is not being followed. If that's not going to suddenly change --- and I
> see
> > no evidence it will --- then asking the UA to apply a mandatory lock is
> > asking the UA to do something impossible, which is generally not a good
> > idea.
> > Rob
>
> Right, not talking about locks any more because it would be telling
> HOW the UA should do it, and what is best for the UA developers is to
> be told WHAT to do.
> Not writing a tutorial but a specification. Let the developer find out
> how to do it, this year, and with the tools that will be available by
> 2020.
>
> Now, out of the locks subject, what I want to be sure of is that the
> specification does not specify the "mutating blob", the origin of this
> thread.
> --
> Juan
>
>
> > "He was pierced for our

Re: Feedback on WebSocket API, Editor's Draft 13 November 2009.

[Sebastian Andersson]

On Mon, Feb 1, 2010 at 10:47, Ian Hickson  wrote:
> On Sun, 31 Jan 2010, Sebastian Andersson wrote:
>> On Sat, Jan 30, 2010 at 10:31, Ian Hickson  wrote:
>> > Right now, today, if I were to expose a WebSocket service on my
>> > Dreamhost shared server, I could do so without any trouble. If we used
>> > a scheme such as the one described above using a policy file, anyone
>> > else also hosting their site on the same server could grant access to
>> > my server to their scripts on their page. Whether this is a technical
>> > or administrative issue, it's an issue we have to handle today.
>>
>> If you only allow the policy file from being read from a single port
>
> How would we do that?

I think it is pretty obvious. Do it like Silverlight! The policy file
is downloaded from port 943. If it is not available there, you have no
right to connect to this IP number.

How do you protect your Web Socket service from another user on your
shared host? They can publish flash clients and java applets that
connects to your server and present any origin they want.

>> > IMHO, yes. I understand that security is a tradeoff between risk and
>> > reward, but fundamentally, it seems to me that it is far off the
>> > "risk/reward" scale to design a system in such a way that a security
>> > problem cannot be fixed when it is discovered. Having the user agent
>> > cache the security policy and act on that cached version even after a
>> > security problem has been found prevents security problems from being
>> > fixed in a timely manner.
>>
>> Sure, it would cause a downtime
>
> We should not design our protocol in such a way that a configuration
> mistake in a security policy can only be fixed by forcing downtime on
> existing users.

But a mistake in the policy file is not enough. The administrator must
make a mistake when writing the policy file, there must be some
malicious code together with users that run the code together with a
service that has a vulnerability running on the same server to get a
problem. If all these things are combined, then you may need some
downtime to fix it (and while you are at it, patch/reconfigure the
service that was vulnerable to protect against native malware of the
same kind).

With a configurable timeout value in the policy file (which is lacking
in flash's policy files, yet they are cached for some time), then the
administrator could even decide what is right for their site.

I think you worry too much about a problem that most administrators
already have to face when deploying java, flash or silverlight
solutions, so they should already be aware of it.

>> With the Web Socket protocol:
>> - Existing services would have to be changed if they should be
>> accessible (with the risk of bugs, duplication of existing access
>> control and logging).
>
> This is intentional, to prevent pages from abusing existing services.

Yes, it was intentional, but it is still a drawback. For me it
prevents all the cases where I would want to use the API today
(replacing existing flash solutions without having to make changes on
the server side).

>> - Requires all new services to implement the policy mechanism correctly.
>
> It's pretty trivial to implement.

Yes, but it still has to be implemented correctly in every server.

>> -- Instead of just having a few correct implementations in the clients
>> (that already have code for origin handling and whose designers
>> hopefully are aware of the problems), each server will have to have it
>> with associated risks of errors. A huge potential for new security
>> problems. Will of course be cheaper and less risky when libraries are
>> available for most languages, but still many more implementations.
>
> I don't understand. Why would the servers have it? It's the client that
> enforces the security policy.

>From section 5.1 in the protocol specification:
"Servers that are not intended to process input from any Web page but
   only for certain sites should verify the "Origin" header is an origin
   they expect, and should only respond with the corresponding
   "WebSocket-Origin" if it is an accepted origin"

I think that covers a large proportion of the servers and I think that
most projects would want to implement support for it just to allow
different server deployment scenarios.

>> - Native clients against a new service would have to use the Web
>> Socket protocol too.
>
> If it's a Web Socket subprotocol... then yes. I wouldn't recommend that
> people use this protocol for designing protocols intended to be used by
> native clients other than browsers, though obviously that's possible too.
>
>> -- Adds a little extra cost and risks. Will of course be cheaper and
>> less risky when libraries are available for most languages, but still
>> way more implementations.
>
> Than what? I'm confused. Web Socket is really trivial to implement -- the
> whole point is to make it easy to implement so anyone can do it. It's like
> CGI, intended for anyone to be able to hack s

Re: XHR LC comment: header encoding

[Julian Reschke]

Anne van Kesteren wrote:

On Tue, 05 Jan 2010 13:49:55 +0100, Boris Zbarsky  wrote:
Apart from the obvious worry of switching away from a behavior that 
the vast majority of UAs currently implement, with the ensuing 
potential for website breakage, sounds fine...


I know... Though Opera not having received bug reports so far on this 
issue gives me some hope, since we have received lots of other bug 
reports on far more minor details starting very early on.


The editor drafts of XHR1 and XHR2 now include the change. This also 
moved things away from being defined in Unicode to a combination of 
bytes and ASCII. Please let me know if you (i.e. anyone reading this 
thread) have any editorial suggestions on my changes or if I missed 
something while making the edits.


Specifically search for "inflate" and "deflate" throughout the drafts:

  http://dev.w3.org/2006/webapi/XMLHttpRequest/
  http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
...


I've got a question. You know have several parts where you say something 
like:


"If any code point in method is higher than U+00FF LATIN SMALL LETTER Y 
WITH DIAERESIS or after deflating method it does not match the Method 
token production raise a SYNTAX_ERR exception and terminate these steps."


a) the part about > U+00FF seems to be redundant with the requirement 
for deflate not to loose information, and


b) as "Method token" (actually "token" in HTTP/1.1) does not allow 
non-ASCII characters anyway, it appears to be much simpler to just 
require conformance to that ABNF.


So this is probably correct, but appears to be way too verbose to me...

Best regards, Julian

Re: Steps to creating a browser standard for the moz-icon:// scheme

[Maciej Stachowiak]

On Feb 1, 2010, at 4:04 AM, Pierre-Antoine LaFayette wrote:

> Yes but in Windows XP they upscale anything over 48x48 I believe.

According to the internets, icons for Windows Vista or later are supposed to 
include bitmaps up to 256x256 (6 total sizes in the standard format) and will 
actually be used. Previous versions of Windows only used sizes up to 64x64. 
Icons for Mac OS X Leopard or later are supposed to include bitmaps up to 
512x512 (also 6 total sizes). Previous versions only went up to 128x128. In all 
cases, the OS will interpolate other sizes.

http://en.wikipedia.org/wiki/Apple_Icon_Image_format
http://en.wikipedia.org/wiki/ICO_(icon_image_file_format)

By contrast, iPhone OS app icons are 57x57.

Regards,
Maciej

> 
> On 1 February 2010 01:24, timeless  wrote:
> 2010/1/29 Pierre-Antoine LaFayette :
> > Perhaps if we found some creative commons icons to use as defaults for the
> > most used extensions. It wouldn't match the native theme but at least we'd
> > have something for cases where platform icons are not available. We'd need
> > to have some number of sizes. I think Windows goes to a max of 72x72, while
> > Mac OSX goes to 128x128. Mozilla defines the size as:
> 
> No. Windows does 256x and OS X does 512x. At least, I've shipped such
> icons on behalf of Nokia and they seemed to match what Windows 7 and
> OS X wanted.
> 
> http://www.macworld.com/article/60877/2007/11/big105icons.html
> http://www.axialis.com/docs/iw/How_to_create_Windows_Vista_compliant_icons.htm
> 
> 
> 
> -- 
> Pierre.

Re: [xhr] events for async requests

[Anne van Kesteren]

On Mon, 01 Feb 2010 13:26:46 +0100, Jonas Sicking  wrote:
On Mon, Feb 1, 2010 at 4:12 AM, Anne van Kesteren   
wrote:
On Mon, 01 Feb 2010 12:56:57 +0100, Jonas Sicking   
wrote:

Where in the spec is this defined? I guess my answer is yes, it'd be
nice if it was more explicit. :)


You haven't even read the specification on this yet? :/

See step 9 under the send() method:

 http://dev.w3.org/2006/webapi/XMLHttpRequest-2/

In particular the two sections flagged with "If the asynchronous flag is
true".


I have read the spec, but I still don't see where it says that
responseText and the state is updated from the same task.


responseText is just an attribute. The specification specifically says to  
update the "response entity body". This makes more sense as well given  
that we will introduce some kind of attribute returning a ByteArray in the  
future.




Is the idea that every bullet under "The same-origin request event
rules are as follows" is always performed from the same task?


Yes.



But even
then the actual updating of the state is not listed in the same set of
bullets.


That does not mean they are a separate task (if that were so it would be  
said). It just means their definition lies somewhere else (to avoid  
duplication).



--
Anne van Kesteren
http://annevankesteren.nl/

Re: Steps to creating a browser standard for the moz-icon:// scheme

[Pierre-Antoine LaFayette]

So it seems like there is a general consensus that at least some parts of
the icon URI scheme are useful and are worth standardizing. One thing I was
confused about was the mention of the File object; I initially believed we
were referring to http://www.mozilla.org/js/js-file-object.html, however, if
I'm not mistaken, I think people actually mean the FileUpload object.

I've summarized the issues discussed thus far:

*Possible Usage Examples:*
# Return the platform icon for the given extension
icon:.zip?size=16&state=disabled # query form
icon:.mp3;16;disabled # short form

# Return the platform icon for the specified file URI
icon:file:///home/pierre/test.png

# Return an icon for a standardized identifier name
icon:stock/gtk-go-up?size=menu
icon:stock/newtab;32;disabled
icon:stock/home;16
icon:stock/refresh;48

*Security risks*
  - Probing???
- Mozilla has been exposing the moz-icon scheme to the web for years.
  - Avoiding Cross-domain theft of arbitrary images; machine fingerprinting
- Canvas getPixelData and toDataURL API calls
  - The only issue has been the cross-domain image theft (
http://scarybeastsecurity.blogspot.com/2008/11/firefox-cross-domain-image-theft-and.html)
vulnerability in Firefox 2 that has since been resolved with cross-domain
checks.
- User interaction visual exploit
  - Gets user to confirm a known pixel is present in the icon image
  - Very loose "exploit"; basically tricking a user into providing
information about her installed applications
  - Mozilla allows this "exploit"
  - Can retrieve the width and height of an image without security checks.

*File URIs in icon scheme*
  - What are the use cases?
- Browser, local html, web sites where files are uploaded by user.
  - Risk of file system probing??
- Maybe if somehow the web site can acess the image data for an icon.
  - Can we use an input File object instead?
- Idea: Get a magic restricted-use URL for that file's icon from the
File object, the same as you can get a URL for the file's contents.
- Idea: The File object could give you an icon: URL that specifically
identifies that file's icon.
- Idea: The File object could give you the data URI for the icon.

*Stock Images*
  - Should we include the "stock" image option in the specification?
- Hard to define a common set of icons (and sizes) across all platforms
- Cross platform: save, zoom in/out, print, folder, file, cut, paste,
copy, delete, add, ok, cancel, about, info, help, quit, strikethrough,
underline, select font, select color, quote, center, left/right align,
change font, text-size, list, bold, italic, etc.
- E.g. http://www.pygtk.org/docs/pygtk/gtk-stock-items.html
- Browser specific: newtab, forward, back, stop, home, refresh, etc.
- Possibly find a set of creative common icons that can always be used
if the platform does not provide the stock icons.
- How do we choose which icons should be included in the stock?

*Icon Sizes*
  - Default image size of 16x16
  - Should sizes be predefined identifiers, e.g. tiny, small, medium,
large?
  - What sizes are acceptable?
  - Platform differences
- Mac OSX supports: 16×16, 32×32, 48×48, 128×128, 256×256 and
512×512 pixels and multiple states
- Windows XP supports: 16x16, 32x32, 48x48 and upscales up to
256x256
- Should an arbitrary integer be allowed causing a potential scaling of
icons?

*Naming of URI*
  - Should we use about:icon or res:icon rather than add a new scheme?
  - IMO, icon: is still the ideal choice.

The two big ones are: the allowance of the file:// syntax versus adding a
getIconURI() type method to the FileUpload object and the support for stock
images.

Perhaps the file:// syntax can work for internal and local pages in the same
way that the file URI only works locally. Whereas the FileUpload object can
be used to retrieve the icon URI or data URI or something. I'm guessing the
icon URI returned would have to be using the icon: syntax?

For the stock images, if people could comment on the plausibility of this
option.

2010/2/1 Ian Fette (イアンフェッティ) 

> Just to be clear, I believe Pierre was referring to file extensions (e.g.
> ".jpg") not browser extensions.
>
> At any rate, I think it would be convenient, if you are able to get a File
> handle, to also be able to get an image representation of the file. That
> could be some thumbnail if the OS has already generated and stored a
> thumbnail and it's essentially free to get it on the platform, or if a
> thumbnail is not available (or perhaps regardless of whether or not a
> thumbnail is available) you could get some other image representation that
> is somehow representative of the file type (e.g. some icon for JPEG files --
> this image does not need to be part of the standard, does not need to be
> consistent across browsers, but should ideally be consistent for all JPEG
> files you call "geticon" on within the same UA on the same computer...
>
> My $0.02
>

Re: [xhr] events for async requests

[Jonas Sicking]

On Mon, Feb 1, 2010 at 4:12 AM, Anne van Kesteren  wrote:
> On Mon, 01 Feb 2010 12:56:57 +0100, Jonas Sicking  wrote:
>>
>> On Mon, Feb 1, 2010 at 3:20 AM, Anne van Kesteren 
>> wrote:

 Can responseText ever be non-empty without being in the LOADING state?
 I.e. do these to actions happen from the same, or from separate, tasks
 posted to the event loop?
>>>
>>> The same.
>>>
>>> I could make this more explicit if you want.
>>
>> Where in the spec is this defined? I guess my answer is yes, it'd be
>> nice if it was more explicit. :)
>
> You haven't even read the specification on this yet? :/
>
> See step 9 under the send() method:
>
>  http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
>
> In particular the two sections flagged with "If the asynchronous flag is
> true".

I have read the spec, but I still don't see where it says that
responseText and the state is updated from the same task.

Is the idea that every bullet under "The same-origin request event
rules are as follows" is always performed from the same task? But even
then the actual updating of the state is not listed in the same set of
bullets.

/ Jonas

Re: [xhr] events for async requests

[Anne van Kesteren]

On Mon, 01 Feb 2010 12:56:57 +0100, Jonas Sicking  wrote:
On Mon, Feb 1, 2010 at 3:20 AM, Anne van Kesteren   
wrote:

Can responseText ever be non-empty without being in the LOADING state?
I.e. do these to actions happen from the same, or from separate, tasks
posted to the event loop?


The same.

I could make this more explicit if you want.


Where in the spec is this defined? I guess my answer is yes, it'd be
nice if it was more explicit. :)


You haven't even read the specification on this yet? :/

See step 9 under the send() method:

  http://dev.w3.org/2006/webapi/XMLHttpRequest-2/

In particular the two sections flagged with "If the asynchronous flag is  
true".



--
Anne van Kesteren
http://annevankesteren.nl/

Re: Steps to creating a browser standard for the moz-icon:// scheme

[Pierre-Antoine LaFayette]

Yes but in Windows XP they upscale anything over 48x48 I believe.

On 1 February 2010 01:24, timeless  wrote:

> 2010/1/29 Pierre-Antoine LaFayette :
> > Perhaps if we found some creative commons icons to use as defaults for
> the
> > most used extensions. It wouldn't match the native theme but at least
> we'd
> > have something for cases where platform icons are not available. We'd
> need
> > to have some number of sizes. I think Windows goes to a max of 72x72,
> while
> > Mac OSX goes to 128x128. Mozilla defines the size as:
>
> No. Windows does 256x and OS X does 512x. At least, I've shipped such
> icons on behalf of Nokia and they seemed to match what Windows 7 and
> OS X wanted.
>
> http://www.macworld.com/article/60877/2007/11/big105icons.html
>
> http://www.axialis.com/docs/iw/How_to_create_Windows_Vista_compliant_icons.htm
>



-- 
Pierre.

Re: [xhr] events for async requests

[Jonas Sicking]

On Mon, Feb 1, 2010 at 3:20 AM, Anne van Kesteren  wrote:
>> Can responseText ever be non-empty without being in the LOADING state?
>> I.e. do these to actions happen from the same, or from separate, tasks
>> posted to the event loop?
>
> The same.
>
> I could make this more explicit if you want.

Where in the spec is this defined? I guess my answer is yes, it'd be
nice if it was more explicit. :)

/ Jonas

Re: Steps to creating a browser standard for the moz-icon:// scheme

[イアンフェッティ]

Just to be clear, I believe Pierre was referring to file extensions (e.g.
".jpg") not browser extensions.

At any rate, I think it would be convenient, if you are able to get a File
handle, to also be able to get an image representation of the file. That
could be some thumbnail if the OS has already generated and stored a
thumbnail and it's essentially free to get it on the platform, or if a
thumbnail is not available (or perhaps regardless of whether or not a
thumbnail is available) you could get some other image representation that
is somehow representative of the file type (e.g. some icon for JPEG files --
this image does not need to be part of the standard, does not need to be
consistent across browsers, but should ideally be consistent for all JPEG
files you call "geticon" on within the same UA on the same computer...

My $0.02

2010/1/31 Maciej Stachowiak 

>
> On Jan 29, 2010, at 10:29 AM, Pierre-Antoine LaFayette wrote:
>
>
>
> 2010/1/29 Ian Fette (イアンフェッティ) 
>
>> 2010/1/28 Maciej Stachowiak 
>>
>>
>>> On Jan 28, 2010, at 8:39 PM, Ian Fette (イアンフェッティ) wrote:
>>>
>>> It's interesting to note that on most modern OSes (Mac OS X, Vista, Win 7
>>> ...) the OS actually does create a pre-computed high quality icon for many
>>> files, e.g. images, PDF, Word, Photoshop,  It is almost free to get this
>>> from the OS, and the OS also has 3 default sizes for it. It would be great
>>> to provide access to this if you have a File handle to it.
>>>
>>>
>>> Mac OS X has 5 default sizes and can reasonably efficiently interpolate
>>> sizes in between. On the other hand, iPhone OS doesn't have any file icons,
>>> or even a really user-visible concept of files. So I'm not sure we can make
>>> too many assumptions about what will hold across platforms.
>>>
>>> Regards,
>>> Maciej
>>>
>>>
>> Sure - there are some platforms where it may not be available (including
>> perhaps winxp?). But it's an interesting idea to expose these if they are
>> available, and if they're not available, then fall back to some default.
>>
>
> Perhaps if we found some creative commons icons to use as defaults for the
> most used extensions. It wouldn't match the native theme but at least we'd
> have something for cases where platform icons are not available. We'd need
> to have some number of sizes. I think Windows goes to a max of 72x72, while
> Mac OSX goes to 128x128. Mozilla defines the size as:
>
>*   Parameter:   size   *   Values:  [ | button | toolbar | 
> toolbarsmall | menu | dialog]   *   Description: If integer, this is the 
> desired size in square pixels of the icon   *Else, use the OS 
> default for the specified keyword context.
>
>
>
>  scales the icons to the desired size. I think we'd at least need a 
> few different sizes for a default set of icons. I'm not sure that such icons 
> exist.
>
>
> I don't see a need to standardize anything solely for use by extensions.
> What we should ask is which icons are useful for Web content, since that is
> where we have the interoperability constraint. Extensions do not currently
> interoperate between different browsers, nor is this planned as far as I can
> tell, so they cannot be the sole use case for any part of a Web standard
> IMO.
>
> Regards,
> Maciej
>
>

Re: [xhr] events for async requests

[Anne van Kesteren]

On Mon, 01 Feb 2010 12:12:18 +0100, Jonas Sicking  wrote:

It is still unclear what the relationship is between responseText
being set to a non-empty value, and switching to the LOADING state is.

Which happens first (it's somewhat clear that responseText is changed
before switching to the LOADING state)?


The response entity body is updated first.



Can responseText ever be non-empty without being in the LOADING state?
I.e. do these to actions happen from the same, or from separate, tasks
posted to the event loop?


The same.


I could make this more explicit if you want.


--
Anne van Kesteren
http://annevankesteren.nl/

Re: [xhr] events for async requests

[Jonas Sicking]

On Mon, Feb 1, 2010 at 2:27 AM, Anne van Kesteren  wrote:
 3. Fire a 'progress', unless 'loadstart' or 'progress' has been fired
 within the past 50ms
>>>
>>> This is already required elsewhere. I suppose I could try to merge the
>>> two, would that be useful?
>>
>> The main point of my email was that responseText should never change
>> other than from the main event loop. I.e. doing xhr.responseText ==
>> xhr.responseText should always return true.
>
> Ok. That is definitely covered now.

It is still unclear what the relationship is between responseText
being set to a non-empty value, and switching to the LOADING state is.

Which happens first (it's somewhat clear that responseText is changed
before switching to the LOADING state)?

Can responseText ever be non-empty without being in the LOADING state?
I.e. do these to actions happen from the same, or from separate, tasks
posted to the event loop?

/ Jonas

Re: [XHR] New api request

[Anne van Kesteren]

On Mon, 01 Feb 2010 11:14:44 +0100, Pedro Santos   
wrote:

At this thread we can point reason to create or not an new api for:
restart, reset, clear states, turn new to reuse, the XHR object. I have
opened another thread to know from the experts the currents workarounds  
to get desired results in reutilization with the current api.


As you wish. I don't see a reason for a new API given that open() ought to  
work (though apparently IE currently has a bug). Also, you could just  
create a new object and let the previous one be garbage collected.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [xhr] events for async requests

[Anne van Kesteren]

On Mon, 01 Feb 2010 03:38:08 +0100, Jonas Sicking  wrote:
On Sun, Jan 31, 2010 at 5:09 AM, Anne van Kesteren   
wrote:
On Wed, 16 Dec 2009 20:46:03 +0100, Jonas Sicking   
wrote:

1. Update .responseText
2. If readystate is not yet 3, set it to 3 and fire readystatechange


This would dispatch readystatechange to often. The specification sides  
with

IE/Opera here rather than WebKit/Gecko.


Huh? This would only fire readystatechange for readyState=3 once per
request. That doesn't seem too often.


My bad. I thought you meant to dispatch readystatechange regardless.



3. Fire a 'progress', unless 'loadstart' or 'progress' has been fired
within the past 50ms


This is already required elsewhere. I suppose I could try to merge the  
two, would that be useful?


The main point of my email was that responseText should never change
other than from the main event loop. I.e. doing xhr.responseText ==
xhr.responseText should always return true.


Ok. That is definitely covered now.


--
Anne van Kesteren
http://annevankesteren.nl/

Re: [XHR2] AnonXMLHttpRequest()

[Anne van Kesteren]

On Mon, 01 Feb 2010 03:45:54 +0100, Jonas Sicking  wrote:
On Sun, Jan 31, 2010 at 1:50 PM, Anne van Kesteren   
wrote:

I'm not really convinced we need all of

 http://dev.w3.org/2006/waf/UMP/

to handle the simple use case it is for. I think UMP can be layered on  
top
of CORS by simply letting the origin be a unique identifier and always  
have

the credentials flag be false. A new constructor could be used for
XMLHttpRequest -- maybe called AnonXMLHttpRequest() -- to enable this
behavior.

Since most people in the WG seem to think we should have both UMP and  
CORS

this solution seems much more straightforward and practical.

Thoughts?


What do you mean by "unique identifier"?


The same as HTML5? I.e. something that results in Origin: null.


--
Anne van Kesteren
http://annevankesteren.nl/

Re: [XHR] New api request

[Pedro Santos]

On Sun, Jan 31, 2010 at 8:38 AM, Anne van Kesteren  wrote:

> On Fri, 29 Jan 2010 14:29:23 +0100, Pedro Santos 
> wrote:
>
>> Hi, how interest is for you develop new APIs in order to enable a reuse of
>> the XMLHttpRequest objects, without the need to call abort method?
>>
>
> No need to ask questions twice :-)
>
> At this thread we can point reason to create or not an new api for:
restart, reset, clear states, turn new to reuse, the XHR object. I have
opened another thread to know from the experts the currents workarounds to
get desired results in reutilization with the current api.

>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>



-- 
Pedro Henrique Oliveira dos Santos

Re: Feedback on WebSocket API, Editor's Draft 13 November 2009.

[Ian Hickson]

On Sun, 31 Jan 2010, Sebastian Andersson wrote:
> On Sat, Jan 30, 2010 at 10:31, Ian Hickson  wrote:
> > Right now, today, if I were to expose a WebSocket service on my 
> > Dreamhost shared server, I could do so without any trouble. If we used 
> > a scheme such as the one described above using a policy file, anyone 
> > else also hosting their site on the same server could grant access to 
> > my server to their scripts on their page. Whether this is a technical 
> > or administrative issue, it's an issue we have to handle today.
> 
> If you only allow the policy file from being read from a single port

How would we do that?


> > IMHO, yes. I understand that security is a tradeoff between risk and 
> > reward, but fundamentally, it seems to me that it is far off the 
> > "risk/reward" scale to design a system in such a way that a security 
> > problem cannot be fixed when it is discovered. Having the user agent 
> > cache the security policy and act on that cached version even after a 
> > security problem has been found prevents security problems from being 
> > fixed in a timely manner.
> 
> Sure, it would cause a downtime

We should not design our protocol in such a way that a configuration 
mistake in a security policy can only be fixed by forcing downtime on 
existing users.


> With the Web Socket protocol:
> - Existing services would have to be changed if they should be
> accessible (with the risk of bugs, duplication of existing access
> control and logging).

This is intentional, to prevent pages from abusing existing services.


> -- This is a huge total cost and a huge potential for security problems.

I think this massively overstates the risks.


> - Requires all new services to implement the policy mechanism correctly.

It's pretty trivial to implement.


> -- Instead of just having a few correct implementations in the clients 
> (that already have code for origin handling and whose designers 
> hopefully are aware of the problems), each server will have to have it 
> with associated risks of errors. A huge potential for new security 
> problems. Will of course be cheaper and less risky when libraries are 
> available for most languages, but still many more implementations.

I don't understand. Why would the servers have it? It's the client that 
enforces the security policy.


> - Native clients against a new service would have to use the Web
> Socket protocol too.

If it's a Web Socket subprotocol... then yes. I wouldn't recommend that 
people use this protocol for designing protocols intended to be used by 
native clients other than browsers, though obviously that's possible too.


> -- Adds a little extra cost and risks. Will of course be cheaper and
> less risky when libraries are available for most languages, but still
> way more implementations.

Than what? I'm confused. Web Socket is really trivial to implement -- the 
whole point is to make it easy to implement so anyone can do it. It's like 
CGI, intended for anyone to be able to hack something up quickly.


> What about someone adding support for Basic authentication in their 
> client, exposing the credentials?

I don't understand this point. What does the Web Socket protocol have to 
do with how you design your subprotocol's authentication?


> - One can't prevent a client from connecting to a port that it should 
> not be allowed to connect to, but the client can't start communications.

No idea what that means.


> -- Yet another DoS vector, but as you've written, there are others so
> then it is ok?

It's not another DOS vector, it's the same DOS vector. You already have to 
handle it. If you're safe from DOSes from  (which have been on the 
Web for 17 years or so now), you're safe from this one.


> - Can be used for port mapping.

No more so than , or XHR, or 

Re: [IndexedDB] Detailed comments for the current draft

[Jeremy Orlow]

On Sun, Jan 31, 2010 at 11:33 PM, Nikunj Mehta  wrote:

>
> On Jan 26, 2010, at 12:47 PM, Pablo Castro wrote:
>
>  These are notes that we collected both from reviewing the spec (editor's
>> draft up to Jan 24th) and from a prototype implementation that we are
>> working on. I didn't realize we had this many notes, otherwise I would have
>> been sending intermediate notes early. Will do so next round.
>>
>>
>> 1. Keys and sorting
>>
>> a.   3.1.1:  it would seem that having also date/time values as keys
>> would be important and it's a common sorting criteria (e.g. as part of a
>> composite primary key or in general as an index key).
>>
>
> The Web IDL spec does not support a Date/Time data type. Could your use
> case be supported by storing the underlying time with millisecond precision
> using an IDL long long type? I am willing to change the spec so that it
> allows long long instead of long IDL type, which will provide adequate
> support for Date and time sorting.


Can the spec not be augmented?  It seems like other specs like WebGL have
created their own types.  If not, I suppose your suggested change would
suffice as well.  This does seem like an important use case.


>  b.  3.1.1: similarly, sorting on number in general (not just
>> integers/longs) would be important (e.g. price lists, scores, etc.)
>>
>
> I am once again hampered by Web IDL spec. Is it possible to leave this for
> future versions of the spec?
>
>
>  c.   3.1.1: cross type sorting and sorting of long values are clear.
>> Sorting of strings however needs more elaboration. In particular, which
>> collation do we use? Does the user or developer get to choose a collation?
>> If we pick up a collation from the environment (e.g. the OS), if the
>> collation changes we'd have to re-index all the databases.
>>
>
> I propose to use Unicode collation algorithm, which was also suggested by
> Jonas during a conversation.
>
>
>  d.  3.1.3: spec reads "…key path must be the name of an enumerated
>> property…"; how about composite keys (would make the related APIs take a
>> DOMString or DOMStringList)
>>
>
> I prefer to leave composite keys to a future version.
>
>
>
>>
>> 2. Values
>>
>> a.   3.1.2: isn't the requirement for "structured clones" too much? It
>> would mean implementations would have to be able to store and retrieve File
>> objects and such. Would it be more appropriate to say it's just graphs of
>> Javascript primitive objects/values (object, string, number, date, arrays,
>> null)?
>>
>
> Your list leaves out File, Blob, FileList, ImageData, and RegExp types.
> While I don't feel so strongly about all these types, I believe that support
> for Blob/File and ImageData will be beneficial to those who work with
> browsers. Instead of profiling this algorithm, I think it is best to just
> require the same algorithm.
>
>
>
>>
>> 3. Object store
>>
>> a.   3.1.3: do we really need in-line + out-of-line keys? Besides the
>> concept-count increase, we wonder whether out-of-line keys would cause
>> trouble to generic libraries, as the values for the keys wouldn't be part of
>> the values iterated when doing a "foreach" over the table.
>>
>
> Certainly it is a matter of prioritizing among various requirements.
> Out-of-line keys enable people to store simple persistent hash maps. I think
> it would be wrong to require that data be always stored as objects. A
> library can always elide the availability of out-of-line keys if that poses
> a problem to its users.
>
>
>  b.  Query processing libraries will need temporary stores, which need
>> temporary names. Should we introduce an API for the creation of temporary
>> stores with transaction lifetime and no name?
>>
>
> Firstly, I think we can leave this safely to a future version. Secondly, my
> suggestion would be to provide a parameter to the create call to indicate
> that an object store being created is a transient one, i.e., not backed by
> durable storage. They could be available across different transactions. If
> your intention is to not make these object stores unavailable across
> connections, then we can also offer a connection-specific transient object
> store.
>
> In general, it requires us to introduce the notion of create params, which
> would simplify the evolution of the API. This is also similar to how
> Berkeley DB handles various options, not just those related to creation of a
> Berkeley "database".
>
>
>  c.  It would be nice to have an estimate row count on each store. This
>> comes at an implementation and runtime cost. Strong opinions? Lacking
>> everything else, this would be the only statistic to base decisions on for a
>> query processor.
>>
>
> I believe we need to have a general way of estimating the number of records
> in a cursor once a key range has been specified. Kris Zyp also brings this
> up in a separate email. I am willing to add an estimateCount attribute to
> IDBCursor for this.
>
>
>  d.  The draft does not touch on h

Re: Some IndexedDB feedback

[Jeremy Orlow]

On Mon, Feb 1, 2010 at 12:02 AM, Nikunj Mehta  wrote:

> Hi all,
>
> Sorry to be slow in responding to all the feedback on Indexed DB. As you
> know, this is now my unpaid work and I am trying my best to respond to
> comments before the weekend is up.
>
> But this is good. Please keep the feedback and early implementation
> experience coming.
>
>
> On Jan 30, 2010, at 5:38 PM, Jeremy Orlow wrote:
>
>  I've started work on implementing the IndexedDB bindings in WebKit as a
>> way to sanity check the API.  I figure it's easiest to trickle feedback to
>> this list rather than save it all up for a big thread, but I'm happy to do
>> that if it's preferred.
>>
>
> I prefer to get incremental comments unless there is a major hole in the
> spec and you need time to digest it and prepare a comprehensive proposal
>
>
>
>> Interfaces I've looked at so far:
>> IDBEnvironment
>> IndexedDatabaseRequest
>> IDBRequest
>> IDBDatabaseError
>> IDBDatabaseException
>>
>>
>> First of all, I just wanted to say that I found the event based nature of
>> IndexedDatabaseRequest/IDBRequest fairly cumbersome.  Why not just have open
>> take in a onsuccess and onerror callbacks and return an object which has the
>> ready state, an abort method, and maybe an error code?  It seems as though
>> the event based API is actually more confusing and artificially limiting
>> (only one open request in flight at a time) than is necessary.
>>
>
> Every approach has its pros and cons. More than with other APIs, a database
> API that is all three - low-level, easy to program, and asynchronous - is
> not easy to get. I don't know for sure that we can satisfy all three. I am
> going to take one more crack at this and have this item on my to-do list.


I'll try to think about this as well and offer some suggestions as I gain
further experience with the API.

 I assume that the limitation is only one database _opening_ in flight at
>> once, and not a limitation that you can only have one database open ever?
>>
>
> Correct. Only one _in-flight_ request on an object. If we had a
> DataCache-style API, every synchronous call would return a result, and an
> asynchronous call would return a "promise". It would be more flexible, but
> no easier to deal with.
>
>
>
>> What is IDBRequest.error when there is no error?  null?  When would it be
>> reset?  The next time you call open?
>>
>
> I have clarified this. Any time request is in INITIAL or LOADING state,
> error is null. It would be reset whenever the request transitions from DONE
> back to LOADING state.
>
>
>
>> What happens when you call abort and there is no pending open?  Is it a
>> no-op?
>>
>
> No-op is the correct behavior.
>
>
>
>> Is it really necessary to have a separate IDBDatabaseException and
>> IDBDatabaseError?  I know one is technically an exception and one is
>> technically an interface, but it seems a bit silly.  Also, it seems as
>> though they both share the same codes, but the codes are only defined in
>> IDBDatabaseException?  If so, I'm not sure it's clear enough in the spec.
>>
>
> Do you have a Web IDL proposal for this? I would love to be correct and
> satisfy you. However, I am not an expert in the business of WebIDL.


I'm pretty sure you know more WebIDL than me.  Maybe there are other experts
on the list that can offer some suggestions.

But really, does IndexedDB really need its own error and exception classes?
>>  At very least, I know the WebSQLDB spec has a very similar error class.
>>  And I suspect there are others, though I didn't immediately find anything
>> looking through the HTML5 spec.
>>
>
> XHR defines codes, but no new exceptions. File API has both and a style
> similar to Indexed Database
>
>
>  Maybe these types of interfaces should be specified in parent specs and
>> not duplicated in those that depend on them?
>>
>
> I am willing to go with whatever works for everyone.


Can any spec/IDL experts offer any suggestions here?


Thanks again, Nikunj

J

Re: [IndexedDB] Detailed comments for the current draft

[Nikunj Mehta]

On Jan 31, 2010, at 11:33 PM, Nikunj Mehta wrote:

d.  The current draft fails to format in IE, the script that  
comes with the page fails with an error


I am aware of this and am working with the maintainer of ReSpec.js  
tool to publish an editor's draft that displays in IE.  Would it be  
OK if this editor's draft that works in IE is made available at an  
alternate W3C URL?


http://dev.w3.org/2006/webapi/WebSimpleDB/post-Overview.html has the  
current static version, which should work in IE. I will try to keep it  
updated, not too far behind the default URL.

Re: Some IndexedDB feedback

[Nikunj Mehta]

Hi all,

Sorry to be slow in responding to all the feedback on Indexed DB. As  
you know, this is now my unpaid work and I am trying my best to  
respond to comments before the weekend is up.


But this is good. Please keep the feedback and early implementation  
experience coming.


On Jan 30, 2010, at 5:38 PM, Jeremy Orlow wrote:

I've started work on implementing the IndexedDB bindings in WebKit  
as a way to sanity check the API.  I figure it's easiest to trickle  
feedback to this list rather than save it all up for a big thread,  
but I'm happy to do that if it's preferred.


I prefer to get incremental comments unless there is a major hole in  
the spec and you need time to digest it and prepare a comprehensive  
proposal




Interfaces I've looked at so far:
IDBEnvironment
IndexedDatabaseRequest
IDBRequest
IDBDatabaseError
IDBDatabaseException


First of all, I just wanted to say that I found the event based  
nature of IndexedDatabaseRequest/IDBRequest fairly cumbersome.  Why  
not just have open take in a onsuccess and onerror callbacks and  
return an object which has the ready state, an abort method, and  
maybe an error code?  It seems as though the event based API is  
actually more confusing and artificially limiting (only one open  
request in flight at a time) than is necessary.


Every approach has its pros and cons. More than with other APIs, a  
database API that is all three - low-level, easy to program, and  
asynchronous - is not easy to get. I don't know for sure that we can  
satisfy all three. I am going to take one more crack at this and have  
this item on my to-do list.




I assume that the limitation is only one database _opening_ in  
flight at once, and not a limitation that you can only have one  
database open ever?


Correct. Only one _in-flight_ request on an object. If we had a  
DataCache-style API, every synchronous call would return a result, and  
an asynchronous call would return a "promise". It would be more  
flexible, but no easier to deal with.




What is IDBRequest.error when there is no error?  null?  When would  
it be reset?  The next time you call open?


I have clarified this. Any time request is in INITIAL or LOADING  
state, error is null. It would be reset whenever the request  
transitions from DONE back to LOADING state.




What happens when you call abort and there is no pending open?  Is  
it a no-op?


No-op is the correct behavior.



Is it really necessary to have a separate IDBDatabaseException and  
IDBDatabaseError?  I know one is technically an exception and one is  
technically an interface, but it seems a bit silly.  Also, it seems  
as though they both share the same codes, but the codes are only  
defined in IDBDatabaseException?  If so, I'm not sure it's clear  
enough in the spec.


Do you have a Web IDL proposal for this? I would love to be correct  
and satisfy you. However, I am not an expert in the business of WebIDL.




But really, does IndexedDB really need its own error and exception  
classes?  At very least, I know the WebSQLDB spec has a very similar  
error class.  And I suspect there are others, though I didn't  
immediately find anything looking through the HTML5 spec.


XHR defines codes, but no new exceptions. File API has both and a  
style similar to Indexed Database


Maybe these types of interfaces should be specified in parent specs  
and not duplicated in those that depend on them?


I am willing to go with whatever works for everyone.



In 3.4.5 probably means to say "events" rather than "callbacks" in  
the first sentence.


Yes



In 3.4.2, queue is mispelled as "aueue".


Gotcha




That's all I have for now.  I've skimmed over the whole spec but  
only read carefully these sections, so please excuse me if any of my  
questions can be answered from text elsewhere in the spec.  (Though  
maybe it would be a sign that the relevant sections should be more  
clear?)


Thanks!
J