from:"Maciej Stachowiak"




On Jul 18, 2008, at 9:58 AM, Aaron Boodman wrote:

On Thu, Jul 17, 2008 at 4:06 PM, Maciej Stachowiak [EMAIL PROTECTED]  
wrote:

On Jul 17, 2008, at 3:53 PM, Aaron Boodman wrote:
I have two minor concerns with this proposal, both in the cases  
where

it differs from Gears:

1. Combining the concepts of 'large chunk of binary data' and 'file'
seems unnecessarily coupled to me. It seems likely that in the  
future

the first concept would be useful in the web api by itself. For
example, in Gears, we have a xhr.responseBlob property. Having a
fileName property here would not always make sense.


I agree! But this proposal doesn't include a concept of 'large  
chunk of
binary data', only a concept of 'file'. It just lets you send the  
file
without first turning it into a chunk of binary data. We're not  
proposing
that the File object should be a generic representation for any  
binary data,

just that it should be sendable via XHR directly.


So you're saying that in the future XHR.send() could be overloaded to
take blob as an argument too? I guess another way to handle it would
be with inheritance -- File could implement Blob, and then you could
change XHR.send() to take Blob instead of File. Either of these are
fine with me.


XHR.send() already takes many things, so one extra overload is not a  
big deal. I can imagine a future design making File be a kind of Blob  
instead of having a Blob as in gears, but the idea is that we don't  
all have to agree on that now.






2. The slice() method seems important for the initial version,
particularly if you are targeting the large upload use case. We use
this to cut up a large file into smaller pieces so that they can be
uploaded individually. This makes the upload resilient and also  
allows

the UI to show progress on the upload.


So far the other requests we have had for this functionality have  
not needed
slicing capability, but nothing in our proposal precludes adding it  
(even

adding it in a way that's identical to the Gears proposal would be
possible).


On Thu, Jul 17, 2008 at 4:32 PM, Sam Weinig [EMAIL PROTECTED] wrote:
Upload progress is possible without manually slicing using the new  
upload

progress events proposed in the XMLHttpRequest Level 2 spec.


Sam's point is good. I forgot that we actually have this in Gears
mainly for resumability of large uploads, not for progress (we have
implemented upload progress too).

I can understand this is less necessary for the initial version.


I wonder if it is possible to make resumability more automatic,  
somewhat like the way If-Range is used to do resumable downloads. But  
manual slicing does seem like an ok solution.


Regards,
Maciej

Re: XDomainRequest Integration with AC

On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote:

I’m in time pressure to lock down the header names for Beta 2 to
integrate XDR with AC. It seems no body has objected to Jonas’s
proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html
Please let me know if this discussion is closed so we can make the
change.

I think Anne's email represents the most recent agreement and I don't
think anyone has objected: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html

The change would be:

Instead of checking for XDomainRequestAllowed: 1 check for Access-
Control-Allow-Origin: * or Access-Control-Allow-Origin: url where
url matches what was sent in the Origin header.

Regards,
Maciej

Namely,
The changes to support the new Access control model is as follows –

· Change Referer header set in the request to Origin.
· Change the XDomainRequestAllowed header check from it
being “1” to check for Access-Control: allow *

In addition, I realized that the discussions we had in the F2F
(tracked by issue 32http://www.w3.org/2008/webapps/track/issues/32)
means that an access control check is now also performed when the
redirect steps are applied to prevent data leakage from intranet
pages. This is different from XDR as we currently do the check in
the final destination for redirection. I think the reason why we did
this in XDR was to allow cross domain resources to move around
easily. That said, I’m not religious about this issue either way.
(Adding my team-mates to hear if they have any concerns). I’ll ask
our dev to make the change, but before that I just wanted to confirm
the AC spec will be updated with this. Currently I couldn’t find
this in the updated spec but I could be wrong.

Thanks,

Re: XDomainRequest Integration with AC



On Jul 18, 2008, at 4:56 PM, Eric Lawrence wrote:

The specific concern with redirections is that we know of instances  
where redirection systems are in use that do not currently support  
addition of custom response headers, and cannot be trivially updated  
to add such headers.  These redirection systems include legacy C++  
applications whose source is no longer available; the only possible  
updates are to the source-destination URLs via a database.  I’ve  
also heard reports of hardware frontend devices with similar  
limitations, although I’m not personally aware of a specific device  
with this limitation.


In general, checking the Access-control response header on every hop  
of a redirection chain may make the access-control specification  
more difficult to deploy in real-world circumstances.


It seems to me that checking every hop is required to avoid  
inadvertent information disclosure. If someone has a service (not  
enabled for Access-Control) which will redirect to the URL of your  
choice but passing some additional info, then by forcing it to  
redirect to a URL that does support Access-Control you can access  
information that you otherwise would not be able to. We should not  
allow systems that don't opt in to be subject to any information  
disclosure, and this seems even more essential if these systems cannot  
be modified.


Regards,
Maciej




-Eric

From: Sunava Dutta
Sent: Friday, July 18, 2008 4:21 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu;  
Gideon Cohn

Cc: public-webapps@w3.org; IE8 Core AJAX SWAT Team
Subject: XDomainRequest Integration with AC

I’m in time pressure to lock down the header names for Beta 2 to  
integrate XDR with AC. It seems no body has objected to Jonas’s  
proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html
Please let me know if this discussion is closed so we can make the  
change.


Namely,
The changes to support the new Access control model is as follows –

· Change Referer header set in the request to Origin.
· Change the XDomainRequestAllowed header check from it  
being “1” to check for Access-Control: allow *


In addition, I realized that the discussions we had in the F2F  
(tracked by issue 32http://www.w3.org/2008/webapps/track/issues/32)  
means that an access control check is now also performed when the  
redirect steps are applied to prevent data leakage from intranet  
pages. This is different from XDR as we currently do the check in  
the final destination for redirection. I think the reason why we did  
this in XDR was to allow cross domain resources to move around  
easily. That said, I’m not religious about this issue either way.  
(Adding my team-mates to hear if they have any concerns).  I’ll ask  
our dev to make the change, but before that I just wanted to confirm  
the AC spec will be updated with this. Currently I couldn’t find  
this in the updated spec but I could be wrong.

Thanks,

Re: XDomainRequest Integration with AC



On Jul 18, 2008, at 5:15 PM, Eric Lawrence wrote:

Can you elaborate on the scenario you’re concerned about?  I cannot  
think of a scenario matching your description that could not be  
exploited using HTML4 Forms alone.


Forms do not give you read access to the target of the redirect,  
whether or not it opts into Access-Control, in the cross-domain case.


Regards,
Maciej



Thanks!
Eric Lawrence
Program Manager - IE Security
Want to view and tamper with HTTP(S) traffic?
Try http://www.fiddler2.com

From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2008 5:07 PM
To: Eric Lawrence
Cc: Sunava Dutta; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa;  
Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT  
Team

Subject: Re: XDomainRequest Integration with AC


On Jul 18, 2008, at 4:56 PM, Eric Lawrence wrote:


The specific concern with redirections is that we know of instances  
where redirection systems are in use that do not currently support  
addition of custom response headers, and cannot be trivially updated  
to add such headers.  These redirection systems include legacy C++  
applications whose source is no longer available; the only possible  
updates are to the source-destination URLs via a database.  I’ve  
also heard reports of hardware frontend devices with similar  
limitations, although I’m not personally aware of a specific device  
with this limitation.


In general, checking the Access-control response header on every hop  
of a redirection chain may make the access-control specification  
more difficult to deploy in real-world circumstances.


It seems to me that checking every hop is required to avoid  
inadvertent information disclosure. If someone has a service (not  
enabled for Access-Control) which will redirect to the URL of your  
choice but passing some additional info, then by forcing it to  
redirect to a URL that does support Access-Control you can access  
information that you otherwise would not be able to. We should not  
allow systems that don't opt in to be subject to any information  
disclosure, and this seems even more essential if these systems  
cannot be modified.


Regards,
Maciej




-Eric

From: Sunava Dutta
Sent: Friday, July 18, 2008 4:21 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu;  
Gideon Cohn

Cc: public-webapps@w3.org; IE8 Core AJAX SWAT Team
Subject: XDomainRequest Integration with AC

I’m in time pressure to lock down the header names for Beta 2 to  
integrate XDR with AC. It seems no body has objected to Jonas’s  
proposal. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0175.html
Please let me know if this discussion is closed so we can make the  
change.


Namely,
The changes to support the new Access control model is as follows –

· Change Referer header set in the request to Origin.
· Change the XDomainRequestAllowed header check from it  
being “1” to check for Access-Control: allow *


In addition, I realized that the discussions we had in the F2F  
(tracked by issue 32http://www.w3.org/2008/webapps/track/issues/32)  
means that an access control check is now also performed when the  
redirect steps are applied to prevent data leakage from intranet  
pages. This is different from XDR as we currently do the check in  
the final destination for redirection. I think the reason why we did  
this in XDR was to allow cross domain resources to move around  
easily. That said, I’m not religious about this issue either way.  
(Adding my team-mates to hear if they have any concerns).  I’ll ask  
our dev to make the change, but before that I just wanted to confirm  
the AC spec will be updated with this. Currently I couldn’t find  
this in the updated spec but I could be wrong.

Thanks,

Re: XDomainRequest Integration with AC

2008-07-20 Thread Maciej Stachowiak




On Jul 20, 2008, at 12:09 PM, Jonas Sicking wrote:


Ian Hickson wrote:

On Sat, 19 Jul 2008, Jonas Sicking wrote:

According to the HTML5 spec space is a valid characted inside URLs.
That wasn't intentional -- can you point to where it says that? The  
HTML5 spec relies on spaces not being allowed in URLs in various  
places.


In section 2.3.2 (Parsing URLs):

# Add all characters with codepoints less than or equal to U+0020 or
# greater than or equal to U+007F to the unreserved production.

And RFC 3986 says:

# Characters that are allowed in a URI but do not have a reserved
# purpose are called unreserved.  These include uppercase and  
lowercase

# letters, decimal digits, hyphen, period, underscore, and tilde.
#
# unreserved  = ALPHA / DIGIT / - / . / _ / ~


That rule is about what conforming HTML5 UAs must do when processing a  
URL with error handling, it does not change what is a valid URI. In  
any case, even if we use the HTML5 parsing algorithm, splitting on  
whitespace before applying it should work. And finally, since we are  
not allowing a path, the main convenience reason for the error  
handling accepting spaces is gone.


Regards,
Maciej

Re: XDomainRequest Integration with AC

2008-07-30 Thread Maciej Stachowiak




On Jul 29, 2008, at 5:52 PM, Sunava Dutta wrote:

Access-Control-Allow-Origin: * seems to be the consensus for the  
public scenario, please confirm.


Yes.

On a less urgent note did we get any further traction on the  
discussion on angle brackets for the URL specified scenario? The  
last mail here seems to be on 7/21.


Jonas and I agreed offline that angle brackets are not required for  
unambiguous parsing.


 - MAciej






-Original Message-
From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 19, 2008 9:32 PM
To: Jonas Sicking
Cc: Sunava Dutta; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon
Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team
Subject: Re: XDomainRequest Integration with AC


On Jul 18, 2008, at 11:15 PM, Jonas Sicking wrote:


Maciej Stachowiak wrote:

On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote:

I'm in time pressure to lock down the header names for Beta 2 to
integrate XDR with AC. It seems no body has objected to Jonas's
proposal. http://lists.w3.org/Archives/Public/public-

webapps/2008JulSep/0175.html

Please let me know if this discussion is closed so we can make the
change.

I think Anne's email represents the most recent agreement and I
don't think anyone has objected:

http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html

The change would be: Instead of checking for
XDomainRequestAllowed: 1 check for Access-Control-Allow-Origin:
* or Access-Control-Allow-Origin: url where url matches what was
sent in the Origin header.


So I have one final request for a change to the above syntax.

How would people feel about the syntax

Access-Control-Allow-Origin: url


I don't think the angle brackets are necessary for forward compat,
since we can just disallow spaces from the URL.

 - Maciej




This would give us at least something for a forwards compatibility
story if we wanted to add to the syntax in future versions of the
spec. I really think we are being overly optimistic if we think that
the current syntax is the be-all end-all syntax that we'll ever  
want.


For example during the meeting we talked about that banks might want
to enforce that the requesting site uses a certain level of
encryption, or even a certain certificate. A syntax for that might

be:


Access-Control-Allow-Origin: origin https://foo.com encryption  
sha1


Or that the site in question uses some opt-in XSS mitigation
technology (such as the one drafted by Brandon Sterns in a previous
thread in this WG). This could be done as

Access-Control-Allow-Origin: origin https://foo.com require-xss-
protection

So the formal syntax would be

Access-Control-Allow-Origin:  (* | url) 

/ Jonas

/ Jonas

Re: ISSUE-44 (EventsAndWindow): Should DOM3 Events cover the interaction of events and the Window object? [DOM3 Events]

2008-08-08 Thread Maciej Stachowiak




On Aug 7, 2008, at 11:27 PM, Jonas Sicking wrote:



Ian Hickson wrote:

On Thu, 7 Aug 2008, Olli Pettay wrote:
Could we actually just say that if document implements  
DocumentView interface and .defaultView isn't null and implements  
EventTarget, the event propagates to .defaultView. So in that case  
defaultView becomes the root of the event target chain (if the  
target of the event is bound to document). No need to mention  
Window, since AbstractView is already defined in DOM2 Views[1].  
HTML5 defines that AbstractView must also implement Window and  
EventTarget interfaces. [2]

Fine by me, so long as the result is compatible with most UAs.


One very unfortunate thing is that if i recall correctly the Window  
object never takes part in the EventTarget chain for the 'load'  
event. But does for all other events. This was because a lot of  
sites broke when we tried to bubble 'load' to the Window.


I think it is best to special-case the 'load' event. We have this same  
quirk in WebKit.


Regards,
Maciej

Re: File Upload Status ?

2008-08-12 Thread Maciej Stachowiak




On Aug 11, 2008, at 11:21 PM, Garrett Smith wrote:



The other problem is that setTimeout does not result in async  
javascript

execution it merely delays the synchronous execution of a script.


I've just tried to upload a 1.1mb log file from my hard drive and had
no issue reading. Using Firefox an older mac.

Reading a 46mb files was slow. I somewhat expected that.

Uploading large files will take time.


Consider that we need this API to work well not only on your system,  
but also under scenarios that have much higher latency to disk, and  
much lower bandwidth from disk, such as:


- network fileshares
- mobile devices with full browsing but limited hardware (such as the  
iPhone or the Nokia e71).


Under these circumstances, reading even a small file can take orders  
of magnitude longer than your measurements.


Your testing illustrates exactly the problem with having a synchronous  
API at all: Web developers will test only on their own system, and  
assume because that is fast enough then a hardcoded limit like this is  
ok.


We've seen the result of this with synchronous XMLHttpRequest, where  
almost any site using it leads to pervasive UI hangs for users on slow  
networks. Let's not repeat that mistake with file access.



In your
example you are returning from readFile (to prevent your code from  
blocking
the UI) and then the moment the timer is triggered a synchronous  
read of a

definitely large file will occur, resulting in the UI being blocked.



That is not what the code was intended to do. I realize that I had a
recursive call in the function readFile. The intention is to
setTimeout(getFileContents, 1);

A useful error might be:
error: file size over allowed limit.
Or in another context:
warning: this file may take time to upload


setTimeout will not prevent a long-running operation from blocking the  
UI. It will merely defer blocking the UI to slightly later. Putting up  
an error is not a good user experience.


The only way to prevent such UI blocking is to have an async api  
regardless
as to whether you have a synchronous one, meaning that the  
synchronous api
will only exist to either increase complexity (as developers will  
need to
implement logic to fallback to, and implement, the async I/O in  
addition to

the synchronous I/O logic as your above example would need to), or to
produce sites that fail to account for non-fast I/O (which thus  
destroy the

end user experience).



Sounds like async reads would avoid the problem of locking the UI.

Why don't you post up your ideas?


We'll probably make a proposal for async reads in time. Our initial  
implementation in WebKit only lets you upload a File object via XHR  
but we believe eventually some form of direct I/O should be added.


Regards,
Maciej

Re: [whatwg] WebIDL and HTML5

2008-08-26 Thread Maciej Stachowiak

On Aug 26, 2008, at 5:22 PM, Garrett Smith wrote:

On Tue, Aug 26, 2008 at 4:47 PM, Jonas Sicking [EMAIL PROTECTED]
wrote:

So let me repeat the question with
the grammatical error fixed. Please do excuse any other grammar
errors I

introduce as English is a second language to me.

3) The behavior of the function when null is passed as value for an
argument is almost always either that of or that of null.
Which one depends on the exact DOM method.

Do you agree with this?

No, I do not agree. If the parameter type is domstring, and null is
not allowed, and the caller passes null, then the current behavior is
implementation-dependent.

1) What DOM methods or attributes are specified to take a DOMString
but disallow null? At least some DOM methods clearly specify how null
should be treated when passed as the value for a DOMString parameter.
There are also many DOM methods and attributes that are not specified
anywhere (except perhaps in the unstable HTML5 Working Draft), which
thus currently have implementation-defined behavior. And many other
methods do not specifically say null is either allowed or disallowed,
which would lead to the presumption that it is allowed, since the
specification of other methods assumes it matches the DOMString type.

I did not agree ever that should be used
when null is passed as a value to an object that expects a string (or
dom method that expects a domstring). I believe that in the
following:-

el.textContent = null;

- with the options:-
a) raise exception
b) textContent is set to null
c) textContent is set to

Option (c) is wrong.
Option (b) would be marginally useful in a few cases
Option (a) would be helpful in some cases (finding bugs)

Option (a) is unacceptable for the following reasons:

1) It does not match existing implementations and thus would likely
break compatibility with existing content.

2) It violates the DOM Level 3 Core specification, which says: On
setting, any possible children this node may have are removed and, if
it the new string is not empty or null, replaced by a single Text node
containing the string this attribute is set to. Thus, clearly
assigning null to textContent must remove all children of the node. http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent

In fact your option (c) appears to be mandated by the spec. Can you
explain why you stated that it is wrong?

Can you explain the reasoning behind your strongly held views on null
used as a string parameter, since they do not seem to line up with
either the DOM specifications or with existing implementations? I can
sympathize with a desire for the handling for null to be clean and
elegant, but unfortunately existing implementations, content and specs
do not allow for such a possibility.

Regards,
Maciej

Re: [whatwg] WebIDL and HTML5

2008-08-26 Thread Maciej Stachowiak




On Aug 26, 2008, at 7:31 PM, Garrett Smith wrote:



Option (a) is unacceptable for the following reasons:

1) It does not match existing implementations and thus would likely  
break

compatibility with existing content.

2) It violates the DOM Level 3 Core specification, which says: On  
setting,
any possible children this node may have are removed and, if it the  
new
string is not empty or null, replaced by a single Text node  
containing the

string this attribute is set to. Thus, clearly assigning null to
textContent must remove all children of the node.
http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent

In fact your option (c) appears to be mandated by the spec. Can you  
explain

why you stated that it is wrong?



No, option (c) is not mandated by the spec. That is clearly not true.

| When it is defined to be null, setting it has no effect.


I think you are misreading the spec. When it is defined to be null  
is not referring to assigning a value of null. It is referring to  
nodeTypes where textContent is null by definition, namely  
DOCUMENT_NODE, DOCUMENT_TYPE_NODE and NOTATION_NODE. Your  
interpretation does not make sense, because it would make the spec  
self-contradictory (it would both say setting to null has no effect,  
and describe the particular effect when setting to nul).



I don't agree that that is a good way to handle null, but it is clear
that these two:

document.body.textContent=null;
document.body.textContent='';

Are specified as being different from each other. They are different
because  is the empty string and null is null. Agreed?


No, the spec requires the identical behavior for both. Please read  
again.



el.textContent = null won't work consistently across browsers. I would
argue that it ought to just set the textContent to null, since it
would make finding the bug easier.


So you are suggesting changing the requirements of the DOM 3 Core  
spec, as well as all existing implementations thereof? Such an extreme  
move would require extraordinary levels of justification.



Can you explain the reasoning behind your strongly held views on  
null used
as a string parameter, since they do not seem to line up with  
either the DOM
specifications or with existing implementations? I can sympathize  
with a
desire for the handling for null to be clean and elegant, but  
unfortunately

existing implementations, content and specs do not allow for such a
possibility.



The spec you mention makes a misfortunate mistake, however, it is not
the mistake that I am concerned with at the moment. The mistakes that
I am more strongly opposed to is the creating of a serialize mapping
of null - .

As I have previously stated, it would be inconsistent to serialize
null to something other than null.


Unfortunately, many DOM methods as specified and widespread DOM  
extensions as implemented treat null and  the same for many string  
arguments. It's true that this is inconsistent with the normal rules  
of the ECMAScript language.


Because we seek to preserve compatibility with the Web and continuity  
with past specifications, the following are not viable options:


- Treating null as the string null in cases where it currently is  
treated as empty string.
- Raising an exception when null is passed for a parameter that  
expects a string, when currently an exception would not be raised.


I think it is a waste of time to discuss these options further, since  
neither the Working Group nor implementors will be open to breaking  
Web compatibility in this way.


Regards,
Maciej

Re: [whatwg] WebIDL and HTML5

2008-08-26 Thread Maciej Stachowiak




On Aug 26, 2008, at 8:12 PM, Garrett Smith wrote:



On Tue, Aug 26, 2008 at 8:04 PM, Boris Zbarsky [EMAIL PROTECTED]  
wrote:

Garrett Smith wrote:


Null is not the empty string.


No one claimed that it was. A number of DOM methods are specified as
treating them equivalently, however.



Well, I'm not so sure. I corresponded with Jonas who indicated that he
though null should convert to . Now Maciej seems to be confused
about textContent = null. The result should be no effect.


No, you read the spec wrong. If you are going to be pendantic and  
criticize others for trivial errors, you should take more care to  
verify your claims.


Regards,
Maciej

Re: [whatwg] WebIDL and HTML5

2008-08-27 Thread Maciej Stachowiak




On Aug 27, 2008, at 2:39 PM, Boris Zbarsky wrote:



Garrett Smith wrote:

Given that, I suggest moving forward:
 Test, then document those methods as having special behavior. Do
this not by a null-value mapping, but by documenting the method's
algorithm in simple terms. e.g. if X is not a string, throw an  
error


But giving a (per-method) mapping means that the algorithm can then  
be machine-generated from the IDL, which is an interoperability win:  
less chance of a mistake being made.


In fact, we already use such IDL annotations in WebKit and it has made  
our DOM bindings more consistent, more interoperable, and less prone  
to breaking through coding errors. I think it is a good model for the  
spec to do the same.


 - Maciej

Re: Regarding DOM 3 Tests Format

2008-09-18 Thread Maciej Stachowiak




On Sep 17, 2008, at 10:29 PM, Garrett Smith wrote:



Hey Chaals, What makes you think that your pious and arrogant attitude
makes you a moderator?  You have no right to dictate what I can say.


The fact that Chaals is a co-Chair of the Web Applications working  
group makes him a moderator of this mailing list, whatever you may  
think of his attitude. http://www.w3.org/2008/webapps/charter/


As co-Chair, it his responsibility to ensure the W3C Process is  
followed. The Individual Participation Criteria in the charter  
require, among other things, Social competence in one's role. http://www.w3.org/2005/10/Process-20051014/policies.html#ParticipationCriteria 



Your repeated rudeness, hostility, personal attacks on Working Group  
members and lack of constructive contribution demonstrate a  
significant lack of social competence. I commend Chaals on his  
decision to help you stick to the Individual Participation Criteria.  
Should you continue to fail to do so, I hope he will take appropriate  
measures to keep you from disrupting the Working Group further.


Regards,
Maciej





And this:

Garrett Smith [EMAIL PROTECTED]
cc  Arthur Barstow [EMAIL PROTECTED],
Doug Schepers [EMAIL PROTECTED],
[EMAIL PROTECTED] [EMAIL PROTECTED]

Is *not* Private mail.  Only you would know why you mailed multiple
people and called it private. I'm putting this on the list so we can
see what kind of person Chaals is.

It looks like you took it upon yourself to go out of your way to
describe me as inappropriate, accusatory, counter-productive and
attacking. You then asked me to stick to demonstrable facts.

We don't really know why you did this.   I pointed out the OP's
mistakes, asked him some questions, and followed with my opinion of
the relevance of YUI Test (Re Hallvord's Comments).  Nobody should
discourage code reviews. Especially not for code that is supposed to
be taken seriously.

Garrett

-- Forwarded message --
From: Charles McCathieNevile [EMAIL PROTECTED]
Date: Wed, Sep 17, 2008 at 5:33 AM
Subject: Re: Regarding DOM 3 Tests Format
To: Garrett Smith [EMAIL PROTECTED]
Cc: Arthur Barstow [EMAIL PROTECTED], Doug Schepers
[EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED]


Private mail:

On Wed, 17 Sep 2008 03:56:35 +0200, Garrett Smith
[EMAIL PROTECTED] wrote:

On Thu, Aug 28, 2008 at 11:12 AM, Carmelo Montanez  
[EMAIL PROTECTED] wrote:


Hi Folks:

I am getting ready to submit a number of tests and wanted to get  
your

feedback on format.  We already agreed
on a template a few weeks back.  This follows on that format.   
Just wanted

to get your view before I go forward.
See attached files.


You obviously did not try running this in any browser.


Hi Garrett,

please refrain from making assumptions about what people do. Opening a
mail with an accusatory or attacking tone of this nature is
counter-productive, and therefore inappropriate for this working
group.

Please keep your comments to demonstrable facts and a more positive
tone in future.

thanks

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
  je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://www.opera.com

Comments on some Web IDL extended attribute names

2008-10-02 Thread Maciej Stachowiak




I think [NativeObject] should be renamed to [Callback]. It is meant to  
be used for callback objects that have a single designated callback  
method, right?


I think [Variadic] should be renamed [Optional]. A function may be  
variadic, but a parameter is optional, and this goes on the parameter.


Regards,
Maciej

Proposal: High resolution (and otherwise improved) timer API

2008-10-02 Thread Maciej Stachowiak



Hello Web Apps WG,

A number of WebKit developers (including from the Chrome team and the  
Safari team) have been discussing ideas for a new and improved timer  
API. We would like to serve the following use cases which we feel are  
not well served by the de facto standard (and now HTML5 standard)  
interfaces of setTimeout and setInterval:


1) True zero-delay timers, to be used to break up long-running  
computations so they can return to the event loop before they  
continue, with minimal additional delay. In most browsers, setTimeout  
and setInterval have an implied minimum timeout of 10ms or 15.6ms,  
meaning they introduce significant delay when used for such purposes.


2) High-resolution timers to be used to precisely drive animations,  
with an easy way to account for timer jitter; a high-resolution timer  
would try to achieve a 60fps frame rate by firing more than 60 times a  
second and drawing the next frame on the cycle closest to the desired  
paint time. Again, more precision than 10-15.6ms is needed here.


3) Long-lasting timers that may need to have their pending duration  
changed before they fire.



We studied the SVGTimer API from SVG Tiny 1.2, and we believe that  
interface is not suitable either, because it makes the simple code for  
case 1 be three lines instead of one, without adding meaningful extra  
benefit in exchange. Here is a rough outline of our proposal:



// should be implemented by Window objects
interface WindowTimer {
Timer startTimer(in double delayInSeconds, in boolean repeating,  
in TimerHandler handler);

}

// starts a timer that will fire in delayInSeconds seconds;  
delayInSeconds may be fractional, and resolution down to at least  
milliseconds should be provided, but user agents may provide even  
smaller resolution. If delayInSeconds is 0, then the timer should be  
considered ready to fire immediately on the next return to the event  
loop. If repeating is true, the timer will fire indefinitely every  
delayInSeconds seconds, until stopped. When the timer fires,  
handler's handleTimer method is called with the timer object as an  
argument.


interface Timer {
void stop(); // stops the timer, if it still has not fired or if  
it is repeating; maybe this should be called cancel()


readonly attribute double timeElapsed; // time in seconds since  
the timer was started or since the last time it fired if repeating and  
it has already fired at least once


void restart([Variadic] in double newDelay);
// if the timer is running it is stopped; then it is restarted  
with newDelay as its delay, or the existing delay if newDelay is  
omitted; the repeating status

// and callback will remain the same.
}

[NativeObject] interface TimerHandler {
void handleTimer(in Timer timer);
}


I think we should put this design or something much like it in a new  
standalone spec, possibly also taking on the legacy setTimeout/ 
setInterval interfaces.


Possible variations discussed:

- Perhaps the delay should be in possibly-fractional milliseconds  
rather than possibly-fractional seconds. But expressing microseconds  
as fractional milliseconds seems quite weird.


- Perhaps the argument order should be (handler, delay, repeating)  
instead, to be more like setTimeout / setInterval


- Perhaps the repeating or even the delayInSeconds arguments  
should be optional, defaulting to false and 0 respectively, and  
possibly in combination with the above suggestion.


- Perhaps there should be separate startTimer and startRepeatingTimer  
functions.



I will also note that this interface does not attempt to be fully  
general; there's no provision for inspecting a timer's callback  
function, for making the first delay be different than the repeat  
delay, for making the timer repeat but only a finite number of times,  
or anything like that. These did not seem like common enough cases to  
warrant bloating the API.



Regards,
Maciej

Re: Proposal: High resolution (and otherwise improved) timer API



On Oct 3, 2008, at 12:03 AM, Geoffrey Garen wrote:


// should be implemented by Window objects
interface WindowTimer {
 Timer startTimer(in double delayInSeconds, in boolean repeating,
in TimerHandler handler);
}


How about a Timer constructor function instead?

Pros:

* Fits the object-oriented programming model of new Image, new  
XMLHttpRequest, etc.


* Enables use of object-oriented features like instanceof,  
the .constructor property, and prototype-based extensions to timer  
objects.


* Distinguishes itself better from the old setTimeout / setInterval  
functions.


In general, the DOM does not depend on a constructor as the only way  
to create a kind of object, since it is nominally language-agnostic.  
In fact, for most things it doesn't provide a constructor invokable as  
such at all; you listed some of the few exceptions.


In addition, new Timer(...) does not as clearly express the fact  
that the timer is not only created but started right away. So I don't  
think a constructor would be good as the sole interface for starting a  
timer.



readonly attribute double timeElapsed; // time in seconds since
elapsedTime reads better to me, since it makes elapsed  
definitely an adjective, and not a verb.


Good suggestion.

Regards,
Maciej

Re: Proposal: High resolution (and otherwise improved) timer API




On Oct 3, 2008, at 1:25 PM, Charles McCathieNevile wrote:

On Fri, 03 Oct 2008 05:43:55 +0200, Maciej Stachowiak  
[EMAIL PROTECTED] wrote:


A number of WebKit developers (including from the Chrome team and  
the Safari team) have been discussing ideas for a new and improved  
timer API.

[...]
I think we should put this design or something much like it in a  
new standalone spec, possibly also taking on the legacy setTimeout/ 
setInterval interfaces.


Note that this group has some minimal but important process  
requirements before it takes on a spec (see the charter[1]). The  
first step (finding someone who agrees to do the editing work -  
otherwise this won't happen) is now underway in the Working Group...


Ian Hickson mentioned that he has a possible candidate editor for this  
spec. I am also willing to edit or co-edit myself.


Regards,
Maciej

Re: [webkit-dev] Proposed Timer API




On Oct 3, 2008, at 11:15 AM, Geoffrey Garen wrote:


Hi Chris.


I really like the idea of a Timer object. It would allow you to
separate creation from starting, allows you to pause and add other
API's to the interface. Can the constructor be used to simplify the
creation:

   var t = new Timer(0, false, function() { ...});

which would start the timer immediately, as in your example.


I think Maciej has made a convincing case that new Timer is a bit  
too coy about the fact that the timer is actually starting.



Or you could do:

   var t = new Timer(function() { ... });
   ...
   t.startOneShot(1.76);


I like your suggestion of adding startOneShot (and  
startRepeating?) to the API. I think it would improve clarity over  
a bool parameter specifying whether the timer repeats.


To create a Timer that isn't scheduled to fire:

new Timer(...)

To create a Timer that is scheduled to fire:

new Timer(...).startOneShot(...)
new Timer(...).startRepeating(...)


It would be pretty unusual for a method like startOneShot or  
startRepeating to return a value. I'm not sure if you indended that;  
if not



Or, if we don't like constructors:

createTimer(...).startOneShot(...)
createTimer(...).startRepeating(...)


We could rename the restart() method to start() (with the same  
semantics, or also taking a bool) and have both createTimer() and  
startTimer() if we think this use case is very important. I don't  
think the need for unstarted timers is very high. However, here's yet  
another tricksy way to achieve the same thing:


var tSpec = [0, false, function() {...});
...
var t = startTimer.apply(window, tSpec);

I think setting up a Timer with the intent of not only starting it but  
defining the timing parameters is extra useless, since then all it  
represents is a function.


Regards,
Maciej





And you could easily add animation or media API's for  
synchronization:


   var t = new Timer(1.76, function() { ... }); // when the timer is
triggered, it will run for 1.76 seconds
   var transition = window.getTransitionForElement(element, left);
   transition.trigger(t);
   ...
   element.style.left = 100px;

This would cause the timer to start when the left transition starts
and fire its event 1.76 seconds later.


This would be really cool!

Geoff

Re: Proposal: High resolution (and otherwise improved) timer API




On Oct 3, 2008, at 9:33 AM, Travis Leithead wrote:


Mmm. A nice addition to the old timeout properties.

I curious to know more about the use-cases and/or problems  
underlying the solution you proposed in #2. Would simply extending  
the current timers to be high-resolution help?:


I believe it is a Web compatibility problem to completely remove the  
resolution limit from setTimeout and setInterval. Since most sites  
have only been tested on existing browsers that have a floor of 10ms  
or 15.6ms, there are a lot of sites that use values like 0 or 1 but go  
haywire if a browser respects that, but work fine with a 10-15ms  
limit. That was our experience in the past


Unfortunately setTimeout cannot be compatibly extended with extra  
parameters either, because Gecko and WebKit browsers already give a  
meaning to extra parameters past the timeout, namely they are passed  
to the callback function as extra arguments. I believe HTML5 even  
standardizes this. So setTimeout(func, 1, foobar) likely exists in  
code already for any reasonable value of foobar.


This led us to the conclusion that a new API was needed.

Regards,
Maciej





2) High-resolution timers to be used to precisely drive animations,

with an easy way to account for timer jitter; a high-resolution timer
would try to achieve a 60fps frame rate by firing more than 60 times a
second and drawing the next frame on the cycle closest to the desired
paint time. Again, more precision than 10-15.6ms is needed here.



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
] On Behalf Of Maciej Stachowiak

Sent: Thursday, October 02, 2008 8:44 PM
To: public-webapps@w3.org Group WG
Subject: Proposal: High resolution (and otherwise improved) timer API


Hello Web Apps WG,

A number of WebKit developers (including from the Chrome team and the
Safari team) have been discussing ideas for a new and improved timer
API. We would like to serve the following use cases which we feel are
not well served by the de facto standard (and now HTML5 standard)
interfaces of setTimeout and setInterval:

1) True zero-delay timers, to be used to break up long-running
computations so they can return to the event loop before they
continue, with minimal additional delay. In most browsers, setTimeout
and setInterval have an implied minimum timeout of 10ms or 15.6ms,
meaning they introduce significant delay when used for such purposes.

2) High-resolution timers to be used to precisely drive animations,
with an easy way to account for timer jitter; a high-resolution timer
would try to achieve a 60fps frame rate by firing more than 60 times a
second and drawing the next frame on the cycle closest to the desired
paint time. Again, more precision than 10-15.6ms is needed here.

3) Long-lasting timers that may need to have their pending duration
changed before they fire.


We studied the SVGTimer API from SVG Tiny 1.2, and we believe that
interface is not suitable either, because it makes the simple code for
case 1 be three lines instead of one, without adding meaningful extra
benefit in exchange. Here is a rough outline of our proposal:


// should be implemented by Window objects
interface WindowTimer {
Timer startTimer(in double delayInSeconds, in boolean repeating,
in TimerHandler handler);
}

// starts a timer that will fire in delayInSeconds seconds;
delayInSeconds may be fractional, and resolution down to at least
milliseconds should be provided, but user agents may provide even
smaller resolution. If delayInSeconds is 0, then the timer should be
considered ready to fire immediately on the next return to the event
loop. If repeating is true, the timer will fire indefinitely every
delayInSeconds seconds, until stopped. When the timer fires,
handler's handleTimer method is called with the timer object as an
argument.

interface Timer {
void stop(); // stops the timer, if it still has not fired or if
it is repeating; maybe this should be called cancel()

readonly attribute double timeElapsed; // time in seconds since
the timer was started or since the last time it fired if repeating and
it has already fired at least once

void restart([Variadic] in double newDelay);
// if the timer is running it is stopped; then it is restarted
with newDelay as its delay, or the existing delay if newDelay is
omitted; the repeating status
// and callback will remain the same.
}

[NativeObject] interface TimerHandler {
void handleTimer(in Timer timer);
}


I think we should put this design or something much like it in a new
standalone spec, possibly also taking on the legacy setTimeout/
setInterval interfaces.

Possible variations discussed:

- Perhaps the delay should be in possibly-fractional milliseconds
rather than possibly-fractional seconds. But expressing microseconds
as fractional milliseconds seems quite weird.

- Perhaps the argument order should be (handler, delay, repeating)
instead, to be more like setTimeout / setInterval

Re: Proposal: High resolution (and otherwise improved) timer API




On Oct 3, 2008, at 10:43 AM, Aaron Boodman wrote:


Hi Maciej,

Thanks for raising this. It's a good addition to the web platform. I'm
definitely +1 to the idea.

2008/10/2 Maciej Stachowiak [EMAIL PROTECTED]:

// should be implemented by Window objects
interface WindowTimer {
  Timer startTimer(in double delayInSeconds, in boolean repeating,  
in TimerHandler handler);

}

- Perhaps the delay should be in possibly-fractional milliseconds  
rather than possibly-fractional seconds. But expressing  
microseconds as fractional milliseconds seems quite weird.


To me, fractional milliseconds does not seem weird. On the webkit-dev
thread, Peter Speck pointed out [1] that the unit of time in web
development is milliseconds. Dates are in milliseconds, setTimeout
takes millisecond arguments, etc. So to me, it would be weird to have
a new timer API that suddenly uses seconds. And I tend to agree with
Peter that doing so would be a common source of bugs for web
developers.


I find the fact that Dates are in milliseconds convincing. It should  
be in milliseconds so people can reasonably do math with Dates and  
elapsedTime.





- Perhaps the argument order should be (handler, delay, repeating)  
instead, to be more like setTimeout / setInterval


- Perhaps the repeating or even the delayInSeconds arguments  
should be optional, defaulting to false and 0 respectively, and  
possibly in combination with the above suggestion.


You mentioned [2] that this is a bit weird because the function can be
quite long and then it reads poorly for anonymous functions.

I see your point, but we already have that problem with setTimeout and
setInterval. And I feel like it's more important to have consistency
where possible with these well-established APIs than fix this issue.


I don't think consistency on argument order is critical, but I see  
your point. We won't be 100% copying the argument order anyway since I  
don't think it is worth carrying over the quirky extra argument  
behavior of setTimeout and setInterval.


Regards,
Maciej

Re: [XHR2] Drop ByteArray?

2008-10-06 Thread Maciej Stachowiak




On Oct 6, 2008, at 5:52 AM, Anne van Kesteren wrote:



I'm considering dropping ByteArray support. That is, removing  
support for it from send() and removing responseBody for now. At  
this point it's not really clear what the future of ByteArray is and  
it seems nobody is driving that work or implementing this feature  
from XMLHttpRequest Level 2.


It would be nice to have access to the raw byte stream, as authors  
currently use ugly hacks to get to it, but higher level support for  
byte streams is somewhat of a prerequisite.


I will ask the ECMAScript committee what the plans are. I think we  
could just invent our own ByteArray or BinaryData interface, it would  
work better integrated into the language, but ImageData as a custom  
type works ok in practice.


Regards,
Maciej

Re: FileUpload Spec | Editor's Draft | Re: Call for Consensus: a new WD of the File Upload spec

2008-10-16 Thread Maciej Stachowiak




On Oct 16, 2008, at 8:02 PM, Maciej Stachowiak wrote:



On Oct 15, 2008, at 10:57 PM, Arun Ranganathan wrote:


Maciej,


My first question would be:

Why did you ignore Apple's proposal to start with a minimal common  
interface (which most people seemed to like) and instead wrote a  
draft that is the union of all things in Robin's original spec,  
all things that Mozilla happened to implement, and a bunch of the  
things that Google propose?


FWIW, the Berjon spec. actually matches implementation in Mozilla,  
modulo a few differences, which I suppose the union reveals.  And  
I *certainly* did not mean to willfully ignore input from anybody.   
I apologize if this is the impression my current draft gives, and  
hope to fix that very soon.  But, looking back on correspondence  
from you, I find one that says you're ok with a WD being published   
but that you think that in a v1 WD, the I/O could be removed  
completely [1].  Sam Weinig voiced Apple's caveats which I  
responded to on public-webapps[2] wondering whether these caveats  
should block at least a WD publication [2], but these were really  
points about synchronous calls in general.


By the way, just to clarify, none of my comments should IMO block  
publishing a Working Draft. A Working Draft is for review. But I do  
think we should start over with a  v1 that is stripped down to the  
bare essentials, along the lines of Sam's proposal.


I will add specifically that Apple is unwilling to implement any spec  
that allows synchronous file I/O from the main thread, and would vote  
against advancing such a spec to LC status or higher. Async I/O would  
be acceptable to us, but I think we have a considerable design process  
to go through in order to agree on how it works. I think the Blob API  
is not suitable as is.


Regards,
Maciej

Re: FileUpload Spec | Editor's Draft | Re: Call for Consensus: a new WD of the File Upload spec

2008-10-16 Thread Maciej Stachowiak




On Oct 16, 2008, at 8:46 PM, Jonas Sicking wrote:


Why did you ignore Apple's proposal to start with a minimal common
interface (which most people seemed to like) and instead wrote a  
draft that
is the union of all things in Robin's original spec, all things  
that Mozilla
happened to implement, and a bunch of the things that Google  
propose?



[1] http://lists.w3.org/Archives/Member/member-webapps/2008OctDec/0010.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0047.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0186.html
[4] http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0387.html


Were you referring to [3] above? I didn't actually realize that  
Apple

was proposing that as a v1 for the FileUpload spec. Apologies for
that, it was certainly not intended to be ignored.
Yes, [3] was our intended proposal for v1 of the file upload spec.  
I don't recall hearing any objection to publishing that as v1.
Arun did not ever respond to that email thread, and your only  
comment was This sounds like a great idea to me.


Nowhere in [3] did it mention that this was a proposal for a v1 of  
the FileUpload spec. In fact, it did not mention at all what to do  
with the proposal, i.e. publish as a Note, add to a new spec, add to  
an existing spec such as XHR Level 2, etc.


I had a vague recollection that the Chairs suggested FileUpload was  
the right track, but I could be wrong. Anyway, sorry for not being  
clear. I would really like it if that set of functionality could be  
published as a baseline v1 of FileUpload, for lack of a better place.



Hence the confusion on my part. My apologies.


I do agree that that API is good and should become part of the web
platform, however I'm not sure that it solves enough use cases  
that it
deserves a spec on its own. Basically it only provides a 'cleaner'  
API

for what you can already do by adding target=a-hidden-iframe on a
form element and calling .submit().
Not true. It lets you upload files with explicit in-page progress  
UI, which form submission cannot do. It lets you perform the upload  
(and show the feedback) from a different frame or window than where  
the user chose the file. It lets you upload multiple files selected  
from a single file control but one at a time and with separate  
progress feedback for each.
These are all specific requests that we have heard from Web  
developers, who are more interested in these features than direct  
access to file bytes without doing an upload.


We added the .files/File API as part of the effort to support  
offline apps. In such a case you need access to the data so that you  
can store it in localStorage, or you need to extend localStorage to  
be able to store File objects rather than just strings.


There are for sure very good use cases for both accessing data as  
well as sending it to the server using XHR.


I think so too. I'm just saying, the XHR-only bit is simpler and  
closer to consensus.




I think at the very least we should provide the ability to get  
access

to the data from within javascript so that you don't have to upload
the data to the server and pull it back down again. Be that through
the mozilla API or the google Blob API (seems like most people are
pushing for the google Blob API so I suspect we'll land on something
like it). That I think is a much bigger enabler for web developers  
and

a higher priority for at least me to get specified.
I don't like either the Mozilla API or the Google Blob API. I think  
it will probably take some time to agree on a good API - I don't  
think the union of everyone's proposals is a good way to do that. I  
think it will take time to come to a consensus on the right API for  
direct access to the file contents - it is a good idea, but there  
are divergent approaches, all with their flaws.


I guess I'm fine with doing a v1 spec that just contains the parts  
in [3] as long as we don't hold off on a spec for accessing data at  
the same time, be that a FileUpload v2 spec or something completely  
separate.


I think it could be FileUpload v2. I think we should start it with  
some strawman proposals and trying to decide some key issues. I will  
post on what I don't like about the Mozilla and Blob models for file I/ 
O.


That does seem like more work editor-wise though, so I'll leave that  
decision to the editor.


I bet Sam would be willing to help edit a pared down v1 spec if it  
would help.


I'm less convinced that we need the FileDialog interface from  
Robin's

original spec as it's basically again just a cleaner API for
something that is already possible.
Instead of cleaner I would say it arguably has more security  
risk, since input type=file binds things to an unforgable user  
action.


From a UI point of view the FileDialog brings up the same UI, no?  
You still get the same filepicker when FileDialog.open is called.  
And you can similarly prevent an input type=file from

Re: FileUpload Spec | Editor's Draft | Re: Call for Consensus: a new WD of the File Upload spec

2008-10-23 Thread Maciej Stachowiak




On Oct 17, 2008, at 11:46 AM, Arun Ranganathan wrote:


All,

Maceij wrote:



[1] http://lists.w3.org/Archives/Member/member-webapps/2008OctDec/0010.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0047.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0186.html
[4] http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0387.html


Were you referring to [3] above? I didn't actually realize that  
Apple

was proposing that as a v1 for the FileUpload spec. Apologies for
that, it was certainly not intended to be ignored.


Yes, [3] was our intended proposal for v1 of the file upload spec.  
I don't recall hearing any objection to publishing that as v1.


Arun did not ever respond to that email thread, and your only  
comment was This sounds like a great idea to me.


1. Again, I apologize for embarking on a direction that wasn't what  
Apple envisioned, but your intention to make [3] above a v1 in  
lieu of the a more expansive spec. wasn't clear to me.  Also, I  
didn't respond to the thread because Jonas' post affirming that it  
... sounds like a great idea... was sufficient.  Thus, I took the  
proposal as a key component in a more expansive spec., but not as a  
v1 spec. in and of itself.


Would you be against making it a v1 spec in and of itself?

Regards,
Maciej

Re: Call for Consensus - Selectors Last Call

2008-10-31 Thread Maciej Stachowiak




I support the publication as Last Call.

On Oct 31, 2008, at 8:06 AM, Charles McCathieNevile wrote:



Hi,

Lachy thinks the latest editor's draft[1] is ready for Last Call,  
after responding to all the comments from last time (and removing  
the NSResolver). The disposition of comments[2] explains what  
happened to those comments.


So this is a call for Consensus to publish the Editor's Draft [1] of  
the Selectors API spec as a Last Call. Please respond before Monday  
November 10. As always, silence is taken as assent but an explicit  
response is preferred.


Opera supports publication of this draft as a Last Call.

[1] http://dev.w3.org/2006/webapi/selectors-api/
[2] http://dev.w3.org/2006/webapi/selectors-api/disposition-of-comments.html

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
   je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8

2009-01-14 Thread Maciej Stachowiak




On Jan 14, 2009, at 3:45 PM, Bil Corry wrote:



Adrian Bateman wrote on 1/14/2009 3:18 PM:
I actually don't think that the generic name is a problem as long  
as the
CSRF solution uses a different name for a different meaning. The  
value really
is an Origin and could potentially be used for more than just  
participation
in the Access Control negotiation. It could still be meaningful in  
other
scenarios in future which would otherwise now have to define a new  
header with

the same meaning.


I'm thinking out loud here, making sure I have the distinction  
between the two correct:


	With Access Control, Origin represents the initial request, which  
survives through a redirect.  So as Adrian points out, it really is  
an Origin.


	With CSRF mitigation, Origin represents the immediately-preceding  
request, which for obvious reasons does not survive through a  
redirect.



That's why I liked the idea of just including the chain of requests  
within Origin, you can then easily find the one you want.  But since  
that isn't on the table, I'm attracted to renaming the CSRF Origin  
to something like Request-Origin.  Whatever name is chosen, it  
then has to be added to the XHR spec as a header that can not  
modified/created via XHR.


Given this behavior, it sounds to me like the Access Control related  
header is more deserving of the term Origin, since it represents the  
true origin of the request. I am not sure what the other header could  
be called to make the difference clear. Perhaps Redirect-Origin? Why  
does the CSRF defense header need to change on redirect?


Regards,
Maciej

Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8

2009-01-14 Thread Maciej Stachowiak




On Jan 14, 2009, at 5:32 PM, Bil Corry wrote:



Maciej Stachowiak wrote on 1/14/2009 6:14 PM:

Why does the CSRF defense header need to change on redirect?


Because to the site on the far end, it would appear the request came  
from somewhere it didn't, effectively hiding the real source of the  
request.  This probably explains it better:


-
When an honest site initiates a request to a dishonest site (for  
example because the user followed a hyperlink), the dishonest site  
can redirect the request back to the honest site. If the redirected  
request carries the same Origin header as the original request, the  
request will implicate the honest site as generating the request. To  
protect the honest site, the user agent replaces the Origin header  
with null, so a conforming server will not modify state in response  
to a redirect.


http://crypto.stanford.edu/websec/specs/origin-header/
-


So one thing to keep in mind is that any POST-based form would not be  
vulnerable to this kind of attack unless the victim site actually  
submits a form to an untrusted site. There is no way for a GET request  
to be redirected to a POST, and it seems to me the practice of Site A  
submitting a form to untrusted site B is likely to be quite rare and  
easily avoidable.


Furthermore, HTML5 specifies that the XXX-Origin (or whatever it might  
get renamed to) header should not be sent for GET requests, the only  
kind of request where it would plausibly help anything.


Thus, the difference in behavior of the CSRF-prevention Origin does  
not do any good, and so we may as well use just one Origin header.


Regards,
Maciej

Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8

2009-01-15 Thread Maciej Stachowiak




On Jan 15, 2009, at 7:24 AM, Bil Corry wrote:


Maciej Stachowiak wrote on 1/15/2009 12:47 AM:

So one thing to keep in mind is that any POST-based form would not be
vulnerable to this kind of attack unless the victim site actually
submits a form to an untrusted site. There is no way for a GET  
request

to be redirected to a POST, and it seems to me the practice of Site A
submitting a form to untrusted site B is likely to be quite rare and
easily avoidable.


Using XSS, an attacker could change the target of a login form to a  
MitM site,


If the site has an XSS vulnerability, then there is no need to stage a  
CSRF attack using a man-in-the-middle server. The injected script  
could perform the equivalent of the CSRF attack directly (for example  
by altering form values and programatically submitting the form).  
Thus, I do not believe it makes sense to defend against this scenario,  
since by assumption the victim site is already owned.


then redirect back to the original target, hiding the attack from  
the user.  If we use Access Control Origin exclusively, then the  
Origin would be the original log-in page, not the attacker's MitM  
site (or NULL), so the attack would be invisible to the site too.


The same would be true just by exploiting the site directly via the  
XSS vulnerability.




Furthermore, HTML5 specifies that the XXX-Origin (or whatever it  
might

get renamed to) header should not be sent for GET requests, the only
kind of request where it would plausibly help anything.


I disagree with the implementation within HTML5; I think it should  
be sent when the GET is going back to the same Origin, so a site can  
confirm that the request came from itself.  I have other ideas about  
redirects, but that's another discussion.


Well, the current HTML5 spec doesn't behave that way, so I think it is  
still the case that it provides practically no benefit. I don't think  
a redirect-tracking Origin on GET requests would have much benefit  
either, since in theory and by HTTP spec, GET-based forms should not  
have dangerous side effects. I realize that this is not true for some  
sites, but it would be easier for a thoughtful site to fix this by  
using POST than to do so by checking Origin on the server side.




Thus, the difference in behavior of the CSRF-prevention Origin does  
not

do any good, and so we may as well use just one Origin header.


The Origin header (as defined in Access Control) will always be the  
page that made the initial request; redirects would be invisible.   
That in itself effectively neuters the CSRF protections.  The only  
way to combine them isn't an option (per this list), so we now need  
two headers to address the specific requirements of each.


The CSRF protections are only defeated in the GET case (where  
currently the CSRF-protection header is specified not to be sent), and  
in the case where the site has hostile content injected via XSS (in  
which case as far as I can tell it is already owned). CSRF protection  
remains effective in the non-XSS non-GET case, which it seems to me is  
arguably the most important case for protection.


Regards,
Maciej

Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8

2009-01-15 Thread Maciej Stachowiak




Hixie said the position I expressed was a little unclear, so I'd like  
to clarify briefly:


1) FACT: The HTML5 version of the CSRF-defense header (currently  
called 'XXX-Origin' as a temporary measure) is specified not to be  
sent for GET requests.
1.a) FACT: As a result, it does not provide any protection  
against CSRF attacks on GET-based forms.
1.b) OPINION: I think this is an OK choice and I do not propose  
changing it. It strikes a decent balance between security and privacy.


2) FACT: Hyperlinks or GET-based forms (which are commonly submitted  
cross-site) cannot redirect to POST-based forms.
2.a) OPINION: Specially marking Origin in the case of redirects  
is not necessary to secure a site's off-site links and GET-based forms  
against CSRF attacks on POST-based forms.


3) FACT: Cross-site form POSTs to untrusted sites are quite rare; and  
furthermore a man-in-the middle attacker redirecting such a request  
cannot change the body of the submission.
3.a) OPINION: Defending against CSRF in this rare case is not  
worth the cost of a second different Origin header, and can be done in  
any case by the site making such bodies readily distinguishable from  
its own form post bodies.


4) FACT: Sites vulnerable to XSS could be vulnerable to a man-in-the- 
middle CSRF as in point 3, but they are owned anyway.
4.a) OPINION: It's not worthwhile to defend XSS-vulnerable sites  
against CSRF, as no meaningful protection is provided.


CONCLUSION: We should use a single Origin header with the name and  
semantics of the Access-Control Origin header for both its Access- 
Control purpose and for redirect defense. The differences in the HTML5  
version are not worth the cost of a very similar but subtly different  
header. And if we ever find the attack in case 3 is more than  
theoretical, we could add a 'Redirected-Via' header to provide full  
information.


Regards,
Maciej

Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8

2009-01-16 Thread Maciej Stachowiak




On Jan 16, 2009, at 9:02 AM, Bil Corry wrote:



Maciej Stachowiak wrote on 1/15/2009 10:40 PM:

CONCLUSION: We should use a single Origin header with the name and
semantics of the Access-Control Origin header for both its
Access-Control purpose and for redirect defense. The differences in  
the

HTML5 version are not worth the cost of a very similar but subtly
different header. And if we ever find the attack in case 3 is more  
than

theoretical, we could add a 'Redirected-Via' header to provide full
information.


Thank you for the extended explanation.  I do now see your point,  
and agree it's probably the best course of action.  It will,  
however, still leave open some odd side-effects from not identifying  
the redirect source, but maybe they're unlikely to be common.  For  
example, Site A allows the users to specify a remote location for  
their avatar image; the user points to Site B, which in turn then  
redirects to Site C.  Site C doesn't like its images being used  
remotely and checks the Origin header and identifies Site A.  Site C  
then complains to Site A about the hotlinking; Site A checks it's  
avatar URLs and doesn't find Site C listed.  So now you have Site C  
being hotlinked from Site A, but Site A has no way to discover how  
it's happening other than to crawl all outbound URLs.


Such hotlinking is probably using a GET request, so no Origin header  
would be sent. I believe it is also outside the scope of the CSRF  
protection and cross-origin data sharing goals of Origin. The Referer  
header is still usable for hotlinking prevention in this scenario, the  
only downside being that it is apparently often filtered by sites or  
users for privacy reasons.


Regards,
Maciej

Re: Seeking implementation status of XBL2

2009-02-10 Thread Maciej Stachowiak




We're interested in implementing XBL2 in WebKit as well, though I  
can't give a specific timetable.


On Feb 10, 2009, at 6:39 AM, Robin Berjon wrote:



On Feb 10, 2009, at 15:27 , Boris Zbarsky wrote:

Robin Berjon wrote:
I don't know if there is precedent in counting JS-based  
implementations as valid implementation to get a spec out the door  
(maybe the Forms WG did it?) but I see no reason not to. In fact,  
I could make the argument that they should count *more* as they  
allow technology to be deployed faster than the browser churn.


Assuming the JS-based implementations actually implement the spec  
as written, yes.  But since the point of the implementation  
requirement is to make sure that the spec is in fact implementable,  
implementations that don't _quite_ implement it shouldn't count  
towards the two interoperable implementations criterion.


Oh, I fully agree with that, the point is not to water down the  
interoperability requirements. I simply want to make sure that JS- 
based implementations are counted as real as there often is a  
misperception that they are somehow just hacks.


Sure, JS-based implementations should count as real if they in fact  
fully implement the spec. However, native browser-hosted  
implementations may well run into issues that may not affect a JS- 
based implementation, and our endgame goal here is to have  
interoperable browser-native implementations. So overall, I think it  
would be unwise to advance the spec to PR on the strength of JS-based  
implementations alone.


Regards,
Maciej

Re: Selectors API

2009-03-24 Thread Maciej Stachowiak



On Mar 23, 2009, at 7:30 AM, Boris Zbarsky wrote:


Anne van Kesteren wrote:

http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0066.html
http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0009.html
I read those. That was long after this was initially discussed  
though. And also around the time I stopped being the active editor  
of the specification.


Er, indeed.  Those seem to be discussion of ElementTraversal.

I was pretty sure I'd raised the same issue with Selectors API, but  
the W3C list search is crappy enough that I can't find the posts...   
In fact, the only thread on the matter I can find is the ACTION-87:  
Selectors API thread (announcing that you plan to start working on  
the spec at) at http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0108.html 
. Was that it?


In any case, the static implementation was considerably more  
complicated in Gecko, I suspect performance is a wash in most cases,  
though it's easy to create examples that are much faster with one or  
the other approach.


Live lists will almost certainly be slower in the face of DOM mutation  
concurrent with iterating the list. I don't know of any reason things  
would be different in Gecko.


In the case of Selectors API especially, a fairly likely use case is  
to mutate the DOM while iterating the list - imagine finding all divs  
with a particular class name, attaching behavior, and then removing  
the class so that behavior is not accidentally added more than once.  
This would be terrible for most conceivable live list implementations.  
Complex selectors (involving indirect adjacent combinators for  
instance) would make things even worse - even DOM mutations that don't  
affect the contents of the list may force invalidation of any caches  
or else a complex calculation to prove they don't change the contents  
of the list.


This is the reason I originally reported that live lists are likely to  
be a performance issue for some common uses of this API.


Regards,
Maciej

Re: Selectors API

2009-03-24 Thread Maciej Stachowiak



On Mar 23, 2009, at 11:08 PM, Maciej Stachowiak wrote:



On Mar 23, 2009, at 7:30 AM, Boris Zbarsky wrote:


Anne van Kesteren wrote:

http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0066.html
http://lists.w3.org/Archives/Public/public-webapi/2007Apr/0009.html
I read those. That was long after this was initially discussed  
though. And also around the time I stopped being the active editor  
of the specification.


Er, indeed.  Those seem to be discussion of ElementTraversal.

I was pretty sure I'd raised the same issue with Selectors API, but  
the W3C list search is crappy enough that I can't find the  
posts...  In fact, the only thread on the matter I can find is the  
ACTION-87: Selectors API thread (announcing that you plan to  
start working on the spec at) at http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0108.html 
. Was that it?


In any case, the static implementation was considerably more  
complicated in Gecko, I suspect performance is a wash in most  
cases, though it's easy to create examples that are much faster  
with one or the other approach.


Live lists will almost certainly be slower in the face of DOM  
mutation concurrent with iterating the list. I don't know of any  
reason things would be different in Gecko.


In the case of Selectors API especially, a fairly likely use case is  
to mutate the DOM while iterating the list - imagine finding all  
divs with a particular class name, attaching behavior, and then  
removing the class so that behavior is not accidentally added more  
than once. This would be terrible for most conceivable live list  
implementations. Complex selectors (involving indirect adjacent  
combinators for instance) would make things even worse - even DOM  
mutations that don't affect the contents of the list may force  
invalidation of any caches or else a complex calculation to prove  
they don't change the contents of the list.


This is the reason I originally reported that live lists are likely  
to be a performance issue for some common uses of this API.


In fact, reading my old post I can see that I already explained the  
perf issues pretty well, including the performance downside of static  
lists, and the idea that you can mitigate this somewhat by a variant  
API that returns only the first match.


I'm still pretty sure you would get O(N^2) behavior in many cases of  
mutating while iterating a live querySelector list, even if live lists  
are easier to implement in Gecko.


Regards,
Maciej

Re: Web Storage SQL

2009-04-09 Thread Maciej Stachowiak



On Apr 9, 2009, at 8:19 AM, Boris Zbarsky wrote:


Giovanni Campagna wrote:

So why not adding a parameter on openDatabase() to specify what kind
of database we want (and what kind of query language we will use)?
I mean something like
openDatabase(name, version, type, displayName, estimatedSize)
where type can be any string
so, for example, type = sql uses the standard SQL, type=sqlite
uses SQLite extensions, type=-vendor-xyz is a vendor specific
extension, etc.


How does this solve the original no such thing as standard SQL,  
really issue?


I agree that no such thing as standard SQL (or rather the fact that  
implementations all have extensions and divergences from the spec) is  
a problem. But I am not sure inventing a brand new query language and  
database model as proposed by Vlad is a good solution to this problem.  
A few thoughts off the cuff in no particular order:


1) Applications are starting to be deployed which use the SQL-based  
storage API, such as the mobile version of GMail. So it may be too  
late for us to remove SQL storage from WebKit entirely. If we want  
this content to interoperate with non-WebKit-based user agents, then  
we will ultimately need a clear spec for the SQL dialect to use, even  
if we also added an OODB or a relational database using some other  
query language.


2) It's true that the server side code for many Web sites uses an  
object-relational mapping layer. However, so far as I know, very few  
use an actual OODB. Relational databases are dominant in the market  
and OODBs are a rarely used niche product. Thus, I question Vlad's  
suggestion than a client-side OODB would sufficiently meet the needs  
of authors. Rather, we should make sure that the platform supports  
adding an object-relational mapping on top of SQL storage.


3) It's not obvious to me that designing and clearly specifying a  
brand new query language would be easier than specifying a dialect of  
SQL. Note that this may require implementations to actually parse  
queries themselves and possibly change them, to ensure that the  
accepted syntax and semantics conform to the dialect. We are ok with  
this.


4) It's not obvious to me that writing a spec for a query language  
with (afaik) a single implementation, such as jLINQ, is easier than  
writing a clear and correct spec for what SQLite does or some subset  
thereof.


Thus, I think the best path forward is to spec a particular SQL  
dialect, even though that task may be boring and unpleasant and not as  
fun as inventing a new kind of database.


Regards,
Maciej

Re: Web Storage SQL

2009-04-10 Thread Maciej Stachowiak



On Apr 9, 2009, at 5:38 PM, Boris Zbarsky wrote:


Maciej Stachowiak wrote:
I agree that no such thing as standard SQL (or rather the fact  
that implementations all have extensions and divergences from the  
spec) is a problem. But I am not sure inventing a brand new query  
language and database model as proposed by Vlad is a good solution  
to this problem.


That's fine; I'm not sure of that either.  I have no particular  
opinion on that question, in fact.


1) Applications are starting to be deployed which use the SQL-based  
storage API, such as the mobile version of GMail. So it may be too  
late for us to remove SQL storage from WebKit entirely.


This is a price of early adoption, sure.

If we want this content to interoperate with non-WebKit-based user  
agents, then we will ultimately need a clear spec for the SQL  
dialect to use, even if we also added an OODB or a relational  
database using some other query language.


That's true, but it's not a given that we want this content to  
interoperate as-is.  Early adopters of known in-flux technologies  
typically realize that they might have to make changes; if a  
different data storage API is decided on, or if the subset of SQL  
that's decided on doesn't match what these apps are using, then  
they'll need to change.


So while I agree that it might be difficult for Webkit to remove the  
SQL support it shipped as soon as some other approach is decided on  
(if that even happens), it doesn't follow that other UAs would need  
to ship SQL support at that point.


There are strong arguments for not breaking existing content, of  
course, but there are also strong arguments for not having  
experimental implementations of early drafts completely dictate the  
standardization process.


I don't think this one point should be decisive by itself. But I don't  
think it should be given zero weight either. I do think the existence  
of an implementation of the current spec and Web content using it  
somewhat raises the burden of proof on anyone proposing a redesign.


Note that one of the clients in question is the offline-enabled mobile  
version of GMail. I think this demonstrates that the SQL-based  
Database Storage can serve the needs of an advanced and polished Web  
application. In addition, we have a rough demonstration that it is  
practically implementable in a modern Web engine.


One clear problem identified despite these examples is that we do not  
have a precise enough spec for the query language to make truly  
independent interoperable implementations possible. It seems to me  
that significantly redesigning database storage is not necessary to  
address this. X is underspecified so let's do Y or Z instead is not  
a very strong argument in my opinion. Another issue raised is that a  
different database model (OODB for instance) may work better for  
content authors. I would say we do not have very compelling evidence  
yet that such a design would be better, or that it could meet the  
various requirements, and we do not even have a concrete strawman  
proposal that we could start evaluating.


Regards,
Maciej

EventSource editorial issues

2009-05-24 Thread Maciej Stachowiak



Section 8 says:

It is better to include a unique identifier in the document when it  
is served and then pass that identifier as part of the URL in the  
src attribute of the eventsource element.


But there is no eventsource element or src attribute defined by this  
specification.



Section 4 says:

Resolve the URL specified in src, relative to the first script's  
base URL.


But the parameter to the constructor is named url not src.


Regards,
Maciej

Re: [selectors-api] Transitioning to CR

2009-06-20 Thread Maciej Stachowiak



On Jun 20, 2009, at 1:39 AM, Charles McCathieNevile wrote:



That's true. THe question is whether a REC makes it easier to get a  
new interoperable implementation. And it's open, as far as I can see.


Assuming we have implementation of everything, twice, and that for  
everything we have at least two implementations that interoperate,  
and that we have a very high level (95% or more) of interoperability  
of at least 3 implementations, and that we have one complete  
implementation, and that we are confident that the barriers to  
completion are now just bugs *that will be fixed* (as opposed to  
bugs that will live forever), the question becomes relevant.


In the meantime, we still don't have any consensus that our test  
suite is ok, so the rest of the question is a bit academic...


... but assuming we get that, and because it seems that we are at  
least very near the above set of assumptions, let's decide whether  
to go the fast or hard way to REC, too. Which means more feedback on  
this question is welcome.


I'd suggest the CR exist criteria should be two implementations that  
100% pass the test suite, i.e. they are individually interoperable on  
every feature, plus agreement from the WG that the test suite is  
correct and thorough. From observed behavior, almost no implementors  
consider the CR level of maturity to be a barrier to adoption, so  
let's do our best to flush out all potential flaws in the spec before  
we go to the essentially frozen state of REC.


Regards,
Maciej

Re: [cors] TAG request concerning CORS Next Step(s)

2009-06-24 Thread Maciej Stachowiak



On Jun 24, 2009, at 4:29 AM, Arthur Barstow wrote:


Members of the Web Apps WG,

Below is an email from Henry Thompson (forwarded with his  
permission), on behalf of the TAG [1], re the CORS spec [2].


Two things:

1. Please respond to at least this part of Henry's mail:

[[
It appeared to us that a number of significant criticisms of the
appropriateness of CORS have been submitted to the Working Group, from
respected members of the Web Security community among others. These
convinced us that there is a real possibility either that server-side
deployment won't happen, or that even if it did the new functionality
provided would, on the one hand, be insufficiently secure while, on  
the

other, discouraging the provision of something more satisfactory.
]]

2. For those that have been active in defining the CORS model and/or  
CORS implementers - particularly Adam, Anne, Jonas, Hixie, Maciej,  
IE guys (whomever replaced Sunava) - please indicate:


a) their level of interest in continuing to push the current CORS  
model;


Apple and the WebKit project would be reluctant to make major changes  
to the model at this point unless its security was broken in ways that  
could not reasonably be patched with minor changes.



b) their implementation plans for CORS.


We have shipped what I believe is an essentially complete  
implementation of CORS as of Safari 4. I believe it is also present or  
soon will be in other WebKt-based browsers, such as Google Chrome.


Regards,
Maciej

Re: Points of order on this WG

2009-06-25 Thread Maciej Stachowiak



On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote:



In any case, adding a new feature to a spec whose future is uncertain
isn't a good idea because it means that the new feature's progress  
is tied
to the uncertain future of the rest of the spec. Thus, my  
recommendation

to Nikunj would be to create a new WG deliverable, not one tied to the
fate of the SQL Database section.


[...]

I think Nikunj's proposal definitely is worthy of being persued,  
just like
the working group is persuing dozens of other proposals like XHR,  
CORS,

Selectors API, Workers, Server-Sent Events, Web Sockets, etc. I don't
believe it really fits into the Web Storage spec (if anything, I  
think we
should split Web Storage into two further specs, not add a third  
wholly
independent feature to it). However, I would definitely support an  
FPWD

publication of Nikunj's proposal, as I have for other proposals.


I strongly agree on these points. I would prefer to see SQL Storage  
split out of the rest of Web Storage. We seem to have rough consensus  
and strong multilateral implementor interest on LocalStorage and  
SessionStorage, and they should be allowed to move forward on the  
standards track quickly. SQL Storage remains contentious, and only  
Apple and Google have shown strong implementor interest so far. And it  
has no technical tie to the other storage drafts. I also think  
Nikunj's proposal should be yet a third separate orthogonal draft.


Regards,
Maciej

Re: Points of order on this WG

2009-06-25 Thread Maciej Stachowiak



On Jun 25, 2009, at 12:42 PM, Nikunj R. Mehta wrote:



I think Nikunj's proposal definitely is worthy of being persued,  
just like
the working group is persuing dozens of other proposals like XHR,  
CORS,

Selectors API, Workers, Server-Sent Events, Web Sockets, etc. I don't
believe it really fits into the Web Storage spec (if anything, I  
think we
should split Web Storage into two further specs, not add a third  
wholly
independent feature to it). However, I would definitely support an  
FPWD

publication of Nikunj's proposal, as I have for other proposals.


That is encouraging. I will be glad to edit an FPWD that includes B- 
tree, interception, and programmable cache, if the WG so prefers.




It seems to me that Berkley DB style database storage, and request  
interception / programmable cache are orthogonal ideas and should  
arguably be separate drafts. I would assume request interception and  
programmable cache are usable regardless of what client-side storage  
APIs are available, much as HTML5 Application Cache is independent of  
these APIs. If anything, it seems more closely related to AppCache  
than to any proposed storage solution.


Regards,
Maciej

Re: Points of order on this WG

2009-06-25 Thread Maciej Stachowiak



On Jun 25, 2009, at 5:23 PM, Jonas Sicking wrote:


On Thu, Jun 25, 2009 at 12:42 PM, Nikunj R.
Mehtanikunj.me...@oracle.com wrote:

On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote:
I have proposed to Mozilla a solution that provides access to an  
organized
key-value database such as that provided in the (open source)  
Berkeley DB.
In essence, a database is a simple B-tree - it keeps keys sorted  
and permits
duplicate keys. It is able to find a key or a key prefix, which  
enables

efficient searching through a very large number of items. If we are
ambitious (i.e., need more functionality), we can add indexes and  
joins to
this spec. There is unlikely to be an interoperability nightmare,  
such as
that which is the most likely outcome with SQL, it does not mandate  
the use
of any query language, and there is at least 40 years of experience  
with it,

including in highly resource-constrained environments. (There are 200
million copies of Berkeley DB in deployment [1]).


This is what so far seems like the best solution to me. I.e. something
that is more backend-ish than what a SQL API would be.

I'd love to see something that allows you to implement a SQL API on
top of. But that also allows you to implement something like MungoDB
very effectively.


I doubt you can efficiently or correctly implement SQL on top of a  
Berkeley-DB-style API.


As a side note, it should be noted Berkeley DB itself could not be  
used by WebKit or Gecko to implement the spec, because even though it  
is open source, the license is not compatible with the LGPL. It seems  
unlikely that non-open-source browser engines could use it either,  
unless they are willing to pay Oracle for a commercial license. So  
it's very important for the spec to be clear and detailed, because  
everyone will have to implement it from scratch.


It's also not clear to me if a BDB-level API is sufficient for  
developer needs. As I understand it, it's basically a giant dictionary  
with unstructured keys and values. So it's not providing much over  
LocalStorage, except for prefix matching and the ability to hold large  
amounts of records or records that are individually large. There's no  
way to efficiently query by one of several fields, as I understand it.


Regards,
Maciej

Re: Points of order on this WG



On Jun 26, 2009, at 12:23 AM, Anne van Kesteren wrote:

On Fri, 26 Jun 2009 01:20:43 +0200, Maciej Stachowiak  
m...@apple.com wrote:
I strongly agree on these points. I would prefer to see SQL Storage  
split out of the rest of Web Storage. We seem to have rough  
consensus and strong multilateral implementor interest on  
LocalStorage and SessionStorage, and they should be allowed to move  
forward on the standards track quickly. SQL Storage remains  
contentious, and only Apple and Google have shown strong  
implementor interest so far. And it has no technical tie to the  
other storage drafts. I also think Nikunj's proposal should be yet  
a third separate orthogonal draft.


FWIW, Opera is implementing SQL storage too.


That's great news! Having multiple independent implementations will, I  
hope, provide more reason to advance the spec.


However, I still think SQL storage should be split from LocalStorage/ 
SessionStorage, since there is no technical reason for them to be tied  
together, and they enjoy different levels of consensus and implementor  
support.


Regards,
Maciej

Re: Points of order on this WG

On Jun 26, 2009, at 10:26 AM, Nikunj R. Mehta wrote:

As a side note, it should be noted Berkeley DB itself could not be
used by WebKit or Gecko to implement the spec, because even though
it is open source, the license is not compatible with the LGPL. It
seems unlikely that non-open-source browser engines could use it
either, unless they are willing to pay Oracle for a commercial
license. So it's very important for the spec to be clear and
detailed, because everyone will have to implement it from scratch.

Huh? what? I hope you had read Oracle's BDB license document [3] and
open source FAQ [4]. IANAL, but I can get answers for your specific
concerns in the context of open source Berkeley DB. AFAICT, someone
like Mozilla would not face any trouble with the open source license
of Berkeley DB. YMMV.

I read the license. By my reading, it imposes requirements that go
beyond WebKit's LGPL license or Gecko's BSD/GPL/LGPL tri-license: http://www.oracle.com/technology/software/products/berkeley-db/htdocs/oslicense.html
. Specifically clause 3 of the license.

It's also not clear to me if a BDB-level API is sufficient for
developer needs. As I understand it, it's basically a giant
dictionary with unstructured keys and values. So it's not providing
much over LocalStorage, except for prefix matching and the ability
to hold large amounts of records or records that are individually
large. There's no way to efficiently query by one of several
fields, as I understand it.

I trust that you are relatively new to storing data with B-trees.
They are at the heart of Oracle's indices so efficiency is out of
question. If you are wondering how can people store complex data
items with multiple fields and repeating values, look at Berkeley DB
Java Edition, which supports the EJB 3 persistence model [5]. FYI,
there is no significant difference between the APIs of BDB Java
Edition and the original BDB. They also have identical licensing
requirements.

Your references do not appear to explain on a technical level how one
stores data with multiple fields in a way that you can query
efficiently by more than one of them. I would appreciate a brief
explanation.

Regards,
Maciej

P.S. I would appreciate if you could discuss technical matters without
mock incredulity or condescension.

Re: Berkeley DB license (was Re: Points of order on this WG)



On Jun 26, 2009, at 3:40 PM, L. David Baron wrote:


On Friday 2009-06-26 15:27 -0700, Nikunj R. Mehta wrote:

I understand the interest in using Berkeley DB in browsers provided
appropriate licensing freedom were available. I am beginning to
understand your concerns vis-à-vis Berkeley DB's license.


To be clear, I wasn't expressing any interest (or disinterest); I
was just commenting on the licensing issues.  I don't have any
opinion on whether we'd want to use it if there weren't licensing
issues (nor would I be the right person to do so).

(I'm just sending this clarification to avoid anyone being under the
incorrect impression that if the license were changed the software
would promptly be incorporated into browsers.  There's still the
issue of convincing browser makers that doing so is important enough
that they'd be willing to support it.)


That's roughly our position for WebKit as well. I did not mean to  
raise the license issue as a showstopper, merely to point out the  
following:


- If we propose an API modeled on Berkeley DB, it likely could not be  
implemented by the popular open source browser engines using Berkeley  
DB itself.


- If we propose an API modeled on Berkeley DB, it likely could not be  
implemented by proprietary browser engines using Berkeley DB itself,  
unless the developers paid licensing fees to oracle.


- Therefore, if we design such an API, we need to be clear and  
detailed enough that it can be implemented interoperably from scratch.


- We also need to be clear that the implementation cost for any  
browser will likely involve implementation from scratch, not just  
plugging in an existing library.


(If Oracle changed the license terms, things would be different, but  
I'm not asking for that and I don't think it's appropriate to ask at  
this early stage.)


Regards,
Maciej

Re: Berkeley DB license (was Re: Points of order on this WG)



On Jun 26, 2009, at 3:46 PM, Nikunj R. Mehta wrote:

FWIW, I came across two pieces about Oracle's open source licensing  
of Berkeley DB that might help clear the air around the licensing  
issues.


First, Oracle's license [1] is word-for-word identical to the  
erstwhile SleepyCat license [2]. Secondly, SleepyCat license  
qualifies as a free software license, and is compatible with the  
GNU General Public License. [3]. Thirdly, the license is OSI  
approved [4].


I am not sure if this resolves issues. It would help if you had  
comments on the above so that I can keep that in my context while  
discussing with our legal staff.


The issue I see with using Berkeley DB for implementation (which I  
think is only a side issue to design of the spec itself) is as  
follows: Clause 3 of the first license (the one with the Oracle  
copyright notice) appears to have stricter source release requirements  
than LGPL. It's not clear to me what exactly the scope of the  
requirement is, but it doesn't seem to have the dynamic linking or  
relinkable object file exceptions of LGPL. That would be a problem for  
projects like WebKit or Gecko that don't want to impost any  
constraints that go beyond the LGPL in their license terms.


I don't want to start a huge debate over this, I just wanted to  
clarify the issue I see.


Regards,
Maciej

Re: Points of order on this WG



On Jun 26, 2009, at 10:51 AM, Nikunj R. Mehta wrote:

Secondly, Oracle proposes adding request interception and  
programmable http cache to the WG's charter. Oracle will provide  
resources for editing and reviewing proposals for all three  
deliverables.


We already have a broad charter and quite a few deliverables. Before  
we add more to the charter, I'd like to understand the degree of  
interest in request interception and programmable http cache. Is  
anyone besides Oracle interested in pursuing this technology? Are any  
implementors interested in implementing it?


Regards,
Maciej

Re: Points of order on this WG



On Jun 26, 2009, at 3:33 PM, Nikunj R. Mehta wrote:

I have a tutorial available to understand how one can use Berkeley  
DB to store data with multiple fields [1]. If you are only  
interested in understanding how to do look up by one or more of  
them, please skip to slide 51.


If this doesn't help, I can write up another explanation for the  
issues that are outstanding.


It sounds like the answer is to make multiple tables with additional  
tables allowing secondary keys to map to the master key. Did I  
understand that correctly? (I'm not sure I got the right idea from the  
pictures).


Can you clarify how a Berkley DB style API would differ from  
LocalStorage in interface or capabilities? What would it be able to do  
that LocalStorage can't?


Regards,
Maciej

Re: An import statement for Web IDL

2009-06-29 Thread Maciej Stachowiak



On Jun 28, 2009, at 10:54 PM, Cameron McCormack wrote:


The OMG-ish IDL fragments published for W3C specs use C preprocessor-
like directives to include other IDL fragments, so that names resolve
correctly.  For example,
http://www.w3.org/TR/DOM-Level-2-Events/idl/events.idl has:



[...]


That way the IDL processor knows exactly what dependent IDL files it
needs to process, and there’s no need to assume that the user of the  
IDL
files has to place the DOM Core and Views IDL files with specific  
names

in the same directory as the events.idl file.

Thoughts?


Specs having to provide actual IDL files and name them seems like a  
burden for spec authors, and not helpful to the spec. It's also not  
helpful for implementations, which do not generally want to have IDL  
files at whole-spec granularity, but rather per-interface.


It would be nice if we could find a way to make things more rigorous  
with a mechanism that's convenient to both spec writers and browser  
developers.


On possibility: we could consistently use modules and have a way to  
import by module name, a la Java. Specs could import other modules  
wholesale with prose or an IDL fragment at the top of the document. We  
could recommend that non-W3C spec specs should use reverse DNS style  
module prefixes to avoid the possibility of collision.


This makes the name binding more rigorous than filename-based includes  
and should not overly get in the way of implementations or specs.


Regards,
Maciej

Re: An import statement for Web IDL

2009-06-30 Thread Maciej Stachowiak



On Jun 29, 2009, at 11:26 PM, Ian Hickson wrote:


On Mon, 29 Jun 2009, Maciej Stachowiak wrote:


It would be nice if we could find a way to make things more rigorous
with a mechanism that's convenient to both spec writers and browser
developers.

On possibility: we could consistently use modules and have a way to
import by module name, a la Java. Specs could import other modules
wholesale with prose or an IDL fragment at the top of the document.  
We
could recommend that non-W3C spec specs should use reverse DNS  
style

module prefixes to avoid the possibility of collision.

This makes the name binding more rigorous than filename-based  
includes

and should not overly get in the way of implementations or specs.


I would rather have just one module for all of the Web platform,  
since at

the end of the day there's only one namespace in JS.


If I were designing things from scratch, I would want to take this  
approach. However, the DOM specs already have their own module names  
and I don't think it's worth changing them. Reserving one particular  
module for all new W3C specifications seems reasonable, but I'm not  
sure it's better than one per spec.


The point of using modules for this at all is to avoid non-W3C  
specifications accidentally or intentionally clashing with the names,  
though on further consideration, it seems like this would cause problems


However, I do think it'd be nice to have tools to help us check the  
IDL.
Could we have a tool that just scans the textContent out of pre  
elements
with class=idl, or something? We could give it the URLs of all the  
specs
being developed, and every hour or day or something it could try to  
fetch
all the specs, check that the IDLs still make sense, and if anything  
bad

happens, post an e-mail to some list we all subscribe to.


Something like that seems like a good idea.

Regards,
Maciej

Re: Web IDL syntax

2009-06-30 Thread Maciej Stachowiak



On Jun 30, 2009, at 7:05 PM, Cameron McCormack wrote:



Maciej Stachowiak:
WebKit doesn't have the same technical constraints as Mozilla,  
however
this change doesn't really seem helpful and it would be annoying to  
have

to replace all instances of DOMString in our existing IDL.


find . -name \*.idl | xargs perl -i -pe s/\DOMString\/string/g

But OK.  By the way, do you use DOMString as an intrinsic type, or do
you use a sequenceunsigned long boxed valuetype (as defined in DOM
Core)?


We treat it as an intrinsic type.

I can easily rename the type back to DOMString.  I’d like to know if  
you

all think there is any problem in keeping the name as DOMString but
removing the null from its set of values, and requiring the use of the
nullable type ‘DOMString?’ to specify a string type that does allow
null.  Because then it is different from the traditional DOMString as
defined in DOM Core.


I haven't investigated this deeply. I'm not sure it is meaningful in  
ECMAScript to say that null is not allowed in some particular case -  
rather, it is necessary to specify what happens when null is passed.  
There's extended attributes to specify that it should be treated as  
, undefined, or null, so it seems odd to have a different type to  
say it should be treated as the string null. I'm not sure if I  
correctly interpreted what you meant by allow null.


Also, as I understand it, there's no way in the Java type system to  
exclude null from the range of a reference type, so there too it's  
necessary to say what happens with a null string (exception, same as  
empty, special behavior different from any string).


Regards,
Maciej

Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject

2009-07-01 Thread Maciej Stachowiak



On Jun 30, 2009, at 11:29 PM, Marcin Hanclik wrote:


What about [ESNativeObject]?


I don't think the property should be ES-specific. It would probably  
have effects for other language bindings too. I'm also not sure this  
clarifies the use of Native.


Regards,
Maciej

Re: An import statement for Web IDL

2009-07-02 Thread Maciej Stachowiak



On Jul 2, 2009, at 12:38 AM, Ian Hickson wrote:


On Thu, 2 Jul 2009, Cameron McCormack wrote:


I don’t know how important it is to keep the HTML interfaces in the
org.w3c.dom.html package, but it definitely seems important to keep  
DOM

Core and Events interfaces in org.w3c.dom and org.w3c.dom.events.


Why? How does it affect black-box compliance of Web-relevant
implementations of those drafts?


It seems to me that there is some benefit to making Java  
implementations of a Web IDL based DOM Core mostly source compatible  
with existing Java DOM bindings. And the cost is low.


I think letting a spec declare a module in one place in prose without  
wrapping all fragments in a module {} declaration could achieve this  
with minimum burden to spec authors.


 - Maciej

Re: Points of order on this WG

2009-07-04 Thread Maciej Stachowiak



On Jul 4, 2009, at 4:56 AM, Charles McCathieNevile wrote:

On Sat, 27 Jun 2009 03:06:21 +0200, Maciej Stachowiak  
m...@apple.com wrote:




On Jun 26, 2009, at 10:51 AM, Nikunj R. Mehta wrote:

Secondly, Oracle proposes adding request interception and  
programmable http cache to the WG's charter. Oracle will provide  
resources for editing and reviewing proposals for all three  
deliverables.


We already have a broad charter and quite a few deliverables.  
Before we add more to the charter, I'd like to understand the  
degree of interest in request interception and programmable http  
cache. Is anyone besides Oracle interested in pursuing this  
technology? Are any implementors interested in implementing it?


We are potentially interested - i.e. we want to see how the spec  
comes out first. Given that this is in the scope of existing  
deliverables, and given taht Oracle are providing the resources to  
edit it, I see no reason to simply stand in their way. If there  
turns out not to be interst, then it will have a tough time getting  
to Rec. There are specs people claim to be very interested in, but  
are not prpared to put ay resources into moving forward - so clearly  
general surveys of interest are a poor way of understanding reality.


I think a B-Tree style storage API would clearly be in scope of  
existing deliverables. However, it's not clear to me that Oracles's  
other proposals (programmable http cache, request interception) are.  
As I understand it, those technologies don't really relate to storage,  
or even networking as such, but are meant to serve a role similar to  
HTML5's Application Cache feature. Also, Nikunj's request was to add  
these things to the charter, from which I infered the charter doesn't  
already obviously cover them.


It's hard for me to evaluate Apple's interest in these technologies  
without seeing a concrete proposal for these features, so I definitely  
don't object to a draft. But I don't see justification for changing  
the charter at this time.


Regards,
Maciej

Re: WebIDL and prototype chains

2009-07-16 Thread Maciej Stachowiak



On Jul 16, 2009, at 3:08 PM, Jonas Sicking wrote:



I definitely agree you definitely don't want the inner windows
prototype values if it's a cross-origin window. What you should get is
less clear to me.

If you should get the outer windows prototype or some sort of blank
prototype. Personally it'd make the most sense to me if you got a
blank prototype since that seems like the most consistent behavior.



Window itself is even more of a special case. What I had in mind is  
objects hanging off of Window that are accessible to a limited extent  
cross-origin, such as History, or Location, or the postMessage  
function. I don't think it would work to give those a blank prototype.  
And you can't just give them the prototype chain from their home  
window because that would be an XSS violation.


Regards,
Maciej

Re: WebIDL and prototype chains

2009-07-16 Thread Maciej Stachowiak



On Jul 16, 2009, at 5:58 PM, Ian Hickson wrote:


On Thu, 16 Jul 2009, Maciej Stachowiak wrote:

On Jul 16, 2009, at 3:08 PM, Jonas Sicking wrote:


I definitely agree you definitely don't want the inner windows
prototype values if it's a cross-origin window. What you should  
get is

less clear to me.

If you should get the outer windows prototype or some sort of blank
prototype. Personally it'd make the most sense to me if you got a
blank prototype since that seems like the most consistent behavior.


Window itself is even more of a special case. What I had in mind is
objects hanging off of Window that are accessible to a limited extent
cross-origin, such as History, or Location, or the postMessage  
function.

I don't think it would work to give those a blank prototype. And you
can't just give them the prototype chain from their home window  
because

that would be an XSS violation.


HTML5 just says that new History, Location, etc, objects are created  
for

each (inner) Window object. Is this not accurate? What do browsers do?


Creating new ones on navigation is indeed correct, but a separate  
issue from making sure cross-origin cross-frame access to things like  
history.back() is safe for both parties.


Regards,
Maciej

Re: WebIDL and prototype chains

2009-07-16 Thread Maciej Stachowiak



On Jul 16, 2009, at 8:04 PM, Ian Hickson wrote:


On Thu, 16 Jul 2009, Maciej Stachowiak wrote:


HTML5 just says that new History, Location, etc, objects are created
for each (inner) Window object. Is this not accurate? What do  
browsers

do?


Creating new ones on navigation is indeed correct, but a separate  
issue

from making sure cross-origin cross-frame access to things like
history.back() is safe for both parties.


In HTML5, you can't access .history cross-domain, and you can't get  
to the
prototype of the .location object (the only thing you can do  
to .location

is set the .href member).

Are these restrictions Web-incompatible?


WebKit-based browsers allow cross-origin back(), forward() and go() on  
History, and replace(), reload() and assign() on Location, in addition  
to setting of href. I can't say definitively that all of those are  
needed to be Web compatible. Firefox allows access to at least  
location.replace() and history.back() cross-domain, and I would  
tentatively guess at least these two are required for Web compatibility.


postMessage() (or, say, focus()) is another example of something that  
needs to be accessible cross-origin, and I don't think you can fully  
hide its prototype because call() and apply() should be usable on it,  
for example.


I haven't thought through exactly how this needs to work. The point is  
mainly that anything accessible cross-origin probably can't just  
follow the normal rules for building a prototype chain.


Regards,
Maciej

Re: DataCache API - editor's draft available

2009-07-22 Thread Maciej Stachowiak



On Jul 21, 2009, at 9:15 PM, Adrian Bateman wrote:


I don't think the problem is that we couldn't build yet another  
cache that is similar but different to the AppCache that others are  
already shipping so I don't think a reference implementation is the  
solution. I think the problem is motivation - are there any use  
cases that adding DataCache enables that couldn't otherwise be  
implemented with what we already have and are those compelling  
enough to complicate the platform with another cache mechanism.  
Further, would we end up with conflicts between the AppCache and the  
DataCache since they're currently not unified as far as I can tell.


[...]

What I'm asking for is a more unified proposal that says If you  
have already implemented AppCache, here's what you add to make the  
same cache provide the additional functionality needed to enable  
these additional use cases. This will inevitably be a compromise  
from what a pure implementation looks like (your current DataCache  
spec, say) but lots of the web is necessarily a compromise because  
it builds on prior art that might not have been ideal but has been  
specified, built and deployed (and not always in that order).


This is pretty close to my own point of view. I think the  
functionality offered by DataCache is interesting, but I'd be much  
more interested in putting it into Safari and WebKit if it was exposed  
as a set of extra AppCache features, rather than a competing and  
unintegrated separate model.


I believe AppCache can reasonably be extended to support the extra  
functionality of DataCache. For example, it should be possible extend  
the manifest format with a way to express that a certain URI should be  
served by script, and to give that script access to a static cached  
copy if it chooses to use it.


This would allow people to form a judgement about whether the  
additional use cases are worth the additional effort instead of  
whether the additional use cases are worth yet another cache. I  
think the ship has already sailed on AppCache and we can't undo that  
even if we wanted to and I don't think a competing solution is the  
right approach.


I agree with this as well. I think extending AppCache is likely to be  
a more successful approach than building a full alternative. I will go  
further and say that if some of the advanced DataCache features were  
expressed as extensions AppCache, we would likely be very interested  
in implementing them.


Regards,
Maciej

Re: DataCache API - editor's draft available

2009-07-22 Thread Maciej Stachowiak



On Jul 21, 2009, at 11:25 PM, Nikunj R. Mehta wrote:


On Jul 21, 2009, at 9:15 PM, Adrian Bateman wrote:

While it might not be the perfect solution (we know the web far  
from

ideal and is a lot of compromise), this type of proposal would be a
lot more compelling to me if I could say This is what we have to
add, this is how, and here are the use cases that make it valuable
with a roadmap for extending what people are already building
instead of something brand new.


Would you mind explaining the last point with a roadmap for  
extending
what people are already building instead of something brand new.  
for

me? I would definitely strive to make the proposal more compelling.


What I'm asking for is a more unified proposal that says If you  
have already implemented AppCache, here's what you add to make the  
same cache provide the additional functionality needed to enable  
these additional use cases. This will inevitably be a compromise  
from what a pure implementation looks like (your current DataCache  
spec, say) but lots of the web is necessarily a compromise because  
it builds on prior art that might not have been ideal but has been  
specified, built and deployed (and not always in that order).


This would allow people to form a judgement about whether the  
additional use cases are worth the additional effort instead of  
whether the additional use cases are worth yet another cache. I  
think the ship has already sailed on AppCache and we can't undo  
that even if we wanted to and I don't think a competing solution is  
the right approach.


What kind of extensions/changes to AppCache would be acceptable at  
this point? In a previous exchange with Ian, he declined to consider  
DataCache like extensions to ApplicationCache for HTML5, which might  
be the reasonable thing to do. I can of course put together a  
proposal, but it would be good to know from browser vendors what  
their preferences are in this matter.


I am open to the idea of incrementally evolving AppCache to be more  
supportive of DataCache requirements.


We'd be willing to consider implementing AppCache extensions in WebKit  
even if they were initially proposed in a separate specification from  
HTML5, assuming there was rough consensus among browser vendors that  
the extensions are a good idea.


I think the ability to have a resource that is served by a client-side  
script would be an example of a reasonable extensions. I'm not totally  
sure how to recast all of the DataCache ideas to fit with the AppCache  
model. I'd be glad to review and provide suggestions, if everyone  
thinks this is a good idea.


Regards,
Maciej

Re: [WebDatabase] Database interface (vs. DatabaseSync interface)

2009-07-27 Thread Maciej Stachowiak



On Jul 27, 2009, at 12:55 PM, Nikunj R. Mehta wrote:



On Jul 25, 2009, at 1:18 PM, Aaron Boodman wrote:


But using workers is a large burden: they are
completely separate JavaScript environments that share nothing with
the main web page. Having to use that for simpler use cases would be
very unfortunate.


I am not sure how large a burden this is. Can you quantify it? Can  
you explain why this would be unacceptable?


The cost of using a Worker is that all interaction with the actual Web  
page and its data is through an asynchronous channel that only allows  
transfer of relatively simple pure data objects (essentially, JSON).  
The advantage is that you can write database access as simple straight- 
line code. If you want to do a lot of database work and don't need to  
interact with page contents or associated JavaScript data structures  
in the middle or very extensively, a Worker using the synchronous API  
will likely work well. If you only want to do a little bit of database  
access, or you need to mix it heavily with page interaction, using the  
async API from the main thread will likely be simpler.




The programming model espoused by WebDatabase's async portion is that:

1. the programmer does all the SQL work in one or more asynchronous  
callbacks.
2. callbacks are always linear, however, the program performs its  
own stack management to keep the requisite context around for doing  
its processing inside asynchronous callbacks. If multiple calls to  
the database are required to perform certain work, then the programs  
become a chain of nested callbacks.
3. the only supported model of transaction isolation is  
serialization of all database access.


This is certainly foreign to most database developers. Editors and/ 
or others share the burden of proof that there is no alternative to  
this and that there is merit in standardizing a brand new  
programming model.


JavaScript actually lets you write a series of nested callbacks in a  
way that looks almost like straight-line code, by using function  
expressions:


db.transaction(function(tx) {
tx.executeSQL(SELECT UserID FROM Users WHERE UserName = ?,  
[userToBan], function(tx, firstResultSet) {

if (resultSet.rows.length  0) {
tx.executeSQL(INSERT INTO BannedUsers VALUES (?),  
resultSet.rows[0]);

}
}
});

(Sorry for the contrived example and my likely syntax errors.)

Granted, this gets awkward if your logic gets considerably more  
complicated.


Regards,
Maciej

Re: [WebDatabase] Database interface (vs. DatabaseSync interface)

2009-07-27 Thread Maciej Stachowiak



On Jul 27, 2009, at 2:14 PM, Nikunj R. Mehta wrote:



And mine did get awkward, very quickly. I found it really hard to  
keep myself sane through the development of asynchronous code that  
executes transactionally and involves multiple sql statements.


My argument is that the program logic gets really complex, really  
fast if you are doing anything complex using Database. On the other  
hand, if your logic and SQL needs are really simple, you might as  
well use the DatabaseSync interface and pay the price of marshaling  
and unmarshaling, which may not be that much.


Aaron showed that it's pretty complex to implement the marshalling in  
a general way on top of Workers and a synchronous interface.




Alternatively, perhaps, we should consider doing something in  
WebWorkers to deal with the overhead of sharing JavaScript objects  
across VMs.


That would lead to far greater complexity for both implementations and  
content authors than the complexity saved by removing the async  
interface.


Regards,
Maciej

Re: Web IDL syntax

2009-08-07 Thread Maciej Stachowiak



On Aug 7, 2009, at 6:23 PM, Cameron McCormack wrote:


Cameron McCormack:

I’ll think about it. :-)  HTMLAppletElement can always have

 readonly attribute DOMString _object;

to avoid conflicting with the reserved word.


Ian Hickson:

It's many years too late for that.


The underscore is just an escaping mechanism.  The identifier is still
just object in this case.


Wouldn't that get in the way of the possibility of underscores in  
identifiers in the future? I think it would be simpler to just  
capitalize the Object keyword.


 - Maciej

Re: CfC: to publish the First Public Working Draft of Web Database spec; deadline 7 September

2009-09-01 Thread Maciej Stachowiak



On Aug 31, 2009, at 11:01 AM, Arthur Barstow wrote:

This is a Call for Consensus (CfC) to publish the First Public  
Working Draft (FPWD) of the Web Database spec:


http://dev.w3.org/html5/webdatabase/

Note that at one point in time, the Web Database spec's  
functionality was included in the Web Storage spec.


As with all of our CfCs, positive response is preferred and  
encouraged and silence will be assumed to be assent. The deadline  
for comments is September 7.


I support publishing.

 - Maciej

Re: [selectors-api] Summary of Feature Requests for v2

2009-09-23 Thread Maciej Stachowiak



On Sep 23, 2009, at 5:26 PM, Jonas Sicking wrote:

On Wed, Sep 23, 2009 at 4:51 AM, Lachlan Hunt lachlan.h...@lachy.id.au 
 wrote:

*Scoped Queries*
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860

This has been discussed extensively in the past.  Basically, the  
idea is
that the selector would be evaluated in the scope of the element,  
in a way

more compatible with how libraries like JQuery work.  This slightly
different from the :scope pseudo-class proposal, see bug for details.


Note that what makes the strong, em selector (which apparently
some libraries support) hard to support spec-wise is that that is not
in fact valid CSS syntax. It's certainly possible to define behavior
for it, it's pretty clear to me how it's intended to work, but it
would mean specifying our own syntax.

However if supporting commaseparated queries is critical for libraries
then I see no other choise. We'll one way or another have to specify
our own syntax, though it can be heavily based on the productions in
the Selector spec.


I think we can define an algorithm for turning an implicitly scoped  
pseudo-selector like strong, em into a proper selector  
using :scope -- in this case :scopestrong, :scopeem. We could  
either have an API entry point that takes a scoped pseudo-selector,  
defined as transforming to a real selector plus establishing a scope  
node, or just present the algorithm as an option for libraries that  
want to expose pseudo-selector syntax.


Regards,
Maciej

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

On Sep 24, 2009, at 5:36 AM, Sam Ruby wrote:

At the upcoming TPAC, there is an opportunity for F2F coordination
between these two groups, and the time slot between 10 O'Clock and
Noon on Friday has been suggested for this.

To help prime the pump, here are four topics suggested by ECMA TC39
for discussion. On these and other topics, there is no need to wait
for the TPAC, discussion can begin now on the es-discuss mailing list.

- - -

The current WebIDL binding to ECMAScript is based on ES3... this
needs to more closely track to the evolution of ES, in particular it
needs to be updated to ES5 w.r.t the Meta Object Protocol. In the
process, we should discuss whether this work continues in the W3C,
is done as a joint effort with ECMA, or moves to ECMA entirely.

It seems like this is a Web IDL issue. I don't see any reason for Web
IDL to move to ECMA. It is a nominally language-independent formalism
that's being picked up by many W3C specs, and which happens to have
ECMAScript as one of the target languages. Much of it is defined by
Web compatibility constraints which would be outside the core
expertise of TC39. Probably the best thing to do is to provide
detailed technical review of Web IDL via the W3C process.

- - -

A concern specific to HTML5 uses WebIDL in a way that precludes
implementation of these objects in ECMAScript (i.e., they can only
be implemented as host objects), and an explicit goal of ECMA TC39
has been to reduce such. Ideally ECMA TC39 and the W3C HTML WG
would jointly develop guidance on developing web APIs, and the W3C
HTML WG would apply that guidance in HTML5.

Meanwhile, I would encourage members of ECMA TC 39 who are aware of
specific issues to open bug reports:

http://www.w3.org/Bugs/Public/

And I would encourage members of the HTML WG who are interested in
this topic to read up on the following emails (suggested by Brendan
Eich):

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
and the rest of that thread

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
(not the transactional behavior, which is out -- just the
interaction with Array's custom [[Put]]).

https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
on an ArrayLike interface with references to DOM docs at the
bottom

https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
about a WebIDL float terminal value issue.

It seems like these are largely Web IDL issues (to the extent I can
identify issues in the threads at all).

- - -

There are larger (and less precise concerns at this time) about
execution scope (e.g., presumptions of locking behavior,
particularly by HTML5 features such as local storage). The two
groups need to work together to convert these concerns into
actionable suggestions for improvement.

There was extensive recent email discussion of local storage locking
on the wha...@whatwg.org mailing list. We could continue here if it
would be helpful. I'm not sure it's useful to discuss in person
without being up to speed on the email discussion. Here are some
relevant threads: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html
.

I'm not sure what the other concerns about execution scope are -
seems hard to discuss fruitfully without more detail.

- - -

We should take steps to address the following willful violation:

If the script's global object is a Window object, then in JavaScript,
the this keyword in the global scope must return the Window object's
WindowProxy object.

This is a willful violation of the JavaScript specification current
at

the time of writing (ECMAScript edition 3). The JavaScript
specification requires that the this keyword in the global scope
return the global object, but this is not compatible with the
security

design prevalent in implementations as specified herein. [ECMA262]

Wasn't ES5 fixed to address this? I know the feedback was passed along.

Regards,
Maciej

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:

Maybe this would be a good opportunity to revisit the utility of
WebIDL in specifications (as formal specifications were re-examined
for ES-Harmony). The WebIDL spec is pretty large, and I personally
have found its use a confounding factor in understanding other specs
(like HTML5).

Its utility is in providing a way to specify API behavior in a way
that is consistent between specifications, language-independent, and
reasonably concise. It's true that it adds an additional thing you
have to learn. That's regrettable, but there are a lot of details that
need to be specified to get interoperability. Pre-WebIDL specs such as
DOM Level 2[1] left many details undefined, leading to problematic
behavior differences among browsers and a need for mutual reverse-
engineering.

Regards,
Maciej

[1] http://www.w3.org/TR/DOM-Level-2-Core/

-- Yehuda

On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich bren...@mozilla.com
wrote:

On Sep 24, 2009, at 7:55 AM, Maciej Stachowiak wrote:

It seems like this is a Web IDL issue. I don't see any reason for
Web IDL to move to ECMA. It is a nominally language-independent
formalism that's being picked up by many W3C specs, and which
happens to have ECMAScript as one of the target languages. Much of
it is defined by Web compatibility constraints which would be
outside the core expertise of TC39.

Some of us on TC39 have lots of Web compatibility experience :-P.

Probably the best thing to do is to provide detailed technical
review of Web IDL via the W3C process.

Expertise on both sides of the artificial standards body divide may
very well be needed. The rest of this message convinces me it is
needed.

One problem with inviting review via the W3C process is getting
attention and following too many firehose-like mailing lists. es-disc...@mozilla.org
is at most a garden hose, which is an advantage.

Another problem is that not all Ecma TC39 members are W3C members
(their employers are not members, that is).

There are transparency problems on both sides, IMHO. People in dark-
glass houses...

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
and the rest of that thread

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
(not the transactional behavior, which is out -- just the
interaction with Array's custom [[Put]]).

https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
on an ArrayLike interface with references to DOM docs at the bottom

https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
about a WebIDL float terminal value issue.

It seems like these are largely Web IDL issues (to the extent I can
identify issues in the threads at all).

TC39 members, Mark Miller articulated this yesterday, hope to
restrict host objects in future versions of the JavaScript standard
from doing any nutty thing they like, possibly by collaborating with
WebIDL standardizers so that instead of anything goes for host
objects, we have only what WebIDL can express.

Catch-all magic where host object interfaces handle arbitrary
property gets and puts are currently not implementable in ES -- this
may be possible in a future edition, but even then it will carry
performance penalties and introduce analysis hazards. We hope to
steer ES bindings for WebIDL-expressed interfaces away from catch-
all patterns.

Beyond this tarpit, we're interested in the best way to linearize
multiply-inherited WebIDL interfaces onto prototype chains, or
whether to use prototype chains at all -- or in the seemingly
unlikely event ES grows first-class method-suite mixins, binding
WebIDL inheritance to those. We would welcome use-cases and
collobaration, at least I would. Who knows what better system might
result?

There was extensive recent email discussion of local storage locking
on the wha...@whatwg.org mailing list. We could continue here if
it would be helpful. I'm not sure it's useful to discuss in person
without being up to speed on the email discussion. Here are some
relevant threads: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022542.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022672.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022993.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/022810.html
.

Thanks for the links, I was aware of these but hadn't read them.

Mandatory try-locks in JS, just say no.

I'm not sure what the other concerns about execution scope are -
seems hard to discuss

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination



On Sep 24, 2009, at 11:11 AM, Yehuda Katz wrote:

Is it really true that WebIDL and the vague way DOM2 was described  
are the only two options? Surely that's a false dilemma?


I'm not saying those are the only two options. I'm explaining how  
WebIDL solves a problem. Are there other ways to solve the problem?  
Probably. Do you have a specific proposal?


Regards,
Maciej



-- Yehuda

On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak m...@apple.com  
wrote:


On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:

Maybe this would be a good opportunity to revisit the utility of  
WebIDL in specifications (as formal specifications were re-examined  
for ES-Harmony). The WebIDL spec is pretty large, and I personally  
have found its use a confounding factor in understanding other  
specs (like HTML5).


Its utility is in providing a way to specify API behavior in a way  
that is consistent between specifications, language-independent, and  
reasonably concise. It's true that it adds an additional thing you  
have to learn. That's regrettable, but there are a lot of details  
that need to be specified to get interoperability. Pre-WebIDL specs  
such as DOM Level 2[1] left many details undefined, leading to  
problematic behavior differences among browsers and a need for  
mutual reverse-engineering.


Regards,
Maciej

[1] http://www.w3.org/TR/DOM-Level-2-Core/




-- Yehuda

On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich bren...@mozilla.com  
wrote:

On Sep 24, 2009, at 7:55 AM, Maciej Stachowiak wrote:

It seems like this is a Web IDL issue. I don't see any reason for  
Web IDL to move to ECMA. It is a nominally language-independent  
formalism that's being picked up by many W3C specs, and which  
happens to have ECMAScript as one of the target languages. Much of  
it is defined by Web compatibility constraints which would be  
outside the core expertise of TC39.


Some of us on TC39 have lots of Web compatibility experience :-P.



Probably the best thing to do is to provide detailed technical  
review of Web IDL via the W3C process.


Expertise on both sides of the artificial standards body divide may  
very well be needed. The rest of this message convinces me it is  
needed.


One problem with inviting review via the W3C process is getting  
attention and following too many firehose-like mailing lists. es-disc...@mozilla.org 
 is at most a garden hose, which is an advantage.


Another problem is that not all Ecma TC39 members are W3C members  
(their employers are not members, that is).


There are transparency problems on both sides, IMHO. People in dark- 
glass houses...




https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
and the rest of that thread

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
(not the transactional behavior, which is out -- just the
interaction with Array's custom [[Put]]).

https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
 on an ArrayLike interface with references to DOM docs at the  
bottom


https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
 about a WebIDL float terminal value issue.

It seems like these are largely Web IDL issues (to the extent I can  
identify issues in the threads at all).


TC39 members, Mark Miller articulated this yesterday, hope to  
restrict host objects in future versions of the JavaScript standard  
from doing any nutty thing they like, possibly by collaborating  
with WebIDL standardizers so that instead of anything goes for  
host objects, we have only what WebIDL can express.


Catch-all magic where host object interfaces handle arbitrary  
property gets and puts are currently not implementable in ES --  
this may be possible in a future edition, but even then it will  
carry performance penalties and introduce analysis hazards. We hope  
to steer ES bindings for WebIDL-expressed interfaces away from  
catch-all patterns.


Beyond this tarpit, we're interested in the best way to linearize  
multiply-inherited WebIDL interfaces onto prototype chains, or  
whether to use prototype chains at all -- or in the seemingly  
unlikely event ES grows first-class method-suite mixins, binding  
WebIDL inheritance to those. We would welcome use-cases and  
collobaration, at least I would. Who knows what better system might  
result?




There are larger (and less precise concerns at this time) about  
execution scope (e.g., presumptions of locking behavior,  
particularly by HTML5 features such as local storage).  The two  
groups need to work together to convert these concerns into  
actionable suggestions for improvement.


There was extensive recent email discussion of local storage  
locking on the wha...@whatwg.org mailing list. We could continue  
here if it would be helpful. I'm not sure it's useful to discuss in  
person without being up to speed on the email discussion. Here are  
some relevant threads: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination



On Sep 24, 2009, at 11:25 AM, Brendan Eich wrote:


On Sep 24, 2009, at 10:48 AM, Maciej Stachowiak wrote:


On Sep 24, 2009, at 9:47 AM, Brendan Eich wrote:

Probably the best thing to do is to provide detailed technical  
review of Web IDL via the W3C process.


Expertise on both sides of the artificial standards body divide  
may very well be needed. The rest of this message convinces me it  
is needed.


One problem with inviting review via the W3C process is getting  
attention and following too many firehose-like mailing lists. es-disc...@mozilla.org 
 is at most a garden hose, which is an advantage.


Another problem is that not all Ecma TC39 members are W3C members  
(their employers are not members, that is).


The converse of all these problems would arise if the spec became  
an ECMA spec.


I'm not advocating that, personally -- I'm explicitly encouraging  
some kind of collaboration across an artificial divide.


This may be difficult for many reasons, but where the spec ends up  
is less important to me (and if you make me choose either-or, I  
prefer w3's RF to Ecma's RAND on first principles) than that we have  
good collaboration without requiring every TC39 member to join w3c  
(if possible).


Any TC39 members whose employers can't join could perhaps become  
Invited Experts to the W3C Web Applications Working Group, if that  
facilitates review.


Do we have to agree on where the spec ends up before collaborating?  
I hope not, especially since it seems likely both ES specs and W3C  
ones may need to contain sub-specs that hook together, possibly  
involving common pieces duplicated among the specs.


We already have a spec in progress and it already has a home, so  
starting the conversation with a suggestion to move the work elsewhere  
struck me as odd and potentially disruptive.



We could recommend avoiding catch-alls as a best practice. However,  
many legacy DOM interfaces require catch-all behavior, so it can't  
be completely eliminated. If we want to restrict host objects to  
what WebIDL allows, but not break the Web, then catch-all getters  
and putters have to be among the things it allows.


The problem is containing the old patterns, heading off the  
temptation to use them in new APIs.


That would probably best be done via a recommendation not to use  
catchalls  in new APIs (in the Web IDL spec perhaps).





Beyond this tarpit, we're interested in the best way to linearize  
multiply-inherited WebIDL interfaces onto prototype chains, or  
whether to use prototype chains at all -- or in the seemingly  
unlikely event ES grows first-class method-suite mixins, binding  
WebIDL inheritance to those. We would welcome use-cases and  
collobaration, at least I would. Who knows what better system  
might result?


Yes, linearization of multiply-inherited interfaces (and multiple  
interfaces that are present but not inherited) is something that  
could use careful review and a better design. When I said these  
are largely Web IDL issues I mean not directly issues for the  
HTML Working Group. I did not mean to imply that TC 39 shouldn't  
have input - it should.


There's probably a better future beyond prototype chains, and I  
think the odds of finding that world and colonizing it are greater  
if we collaborate somehow. The current situation is making the best  
of de-facto standards, rationalizing what's out there.


Indeed, because the variance in what's out there makes life more  
difficult for authors. I expect it's not possible to get rid of  
prototypes from ECMAScript DOM bindings given the constraints of Web  
compatibility.




Possibly TC39 members need to do the main work on mixins, and then  
propose something coherent for WebIDL to bind to. But I know of  
folks not active in TC39 or not even Ecma mebmers, who are able to  
participate in the public HTML5 lists (and of course in whatwg.org),  
who do want mixins a la Ruby modules in JS, and their input would  
help us make some kind of progress.


But this separation of producers and consumers is artificial,  
and it may miss critical information not expressed in mythical  
waterfall requirements docs one might imagine the parties exchange.  
Systems RD benefits from mixing up the experts and opening the  
silos to cross disciplines, interest areas, programming audiences,  
and less defensible boundaries to-do with standards body politics.


The current division of labor between core language (Ecma) and DOM/ 
WebAPI/WebIDL (W3C) has its advantages, don't get me wrong. But  
obviously some things have fallen through the cracks (multiple  
globals, split windows, execution rules).


I think we are in agreement that collaboration would enable a better  
outcome here. All I meant to do is to point out the proper W3C Working  
Group for coordination.




The term I used was execution model. scope is a mis- 
transcription.


Are there specific issues other than the concurrency model for  
storage APIs

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination



On Sep 24, 2009, at 12:00 PM, Yehuda Katz wrote:

I'll think about it. I was mostly hoping to start a discussion about  
alternatives. I think the bottom line here is that while the spec is  
well-optimized for implementors, it is not very well optimized for  
consumers. I suppose it would be possible to say that this stuff is  
*only* for implementors. I'd prefer if it were also readable for  
those trying to use the specification.


My inclination would be to address this by improving the current Web  
IDL spec,  or to write an informative primer style document to  
accompany it. I also think some of the complexity of the Web IDL spec  
can probably be removed without losing anything important - I think it  
offers some constructs that are not used by any spec relying on it.


 - Maciej



-- Yehuda

On Thu, Sep 24, 2009 at 11:17 AM, Maciej Stachowiak m...@apple.com  
wrote:


On Sep 24, 2009, at 11:11 AM, Yehuda Katz wrote:

Is it really true that WebIDL and the vague way DOM2 was described  
are the only two options? Surely that's a false dilemma?


I'm not saying those are the only two options. I'm explaining how  
WebIDL solves a problem. Are there other ways to solve the problem?  
Probably. Do you have a specific proposal?


Regards,
Maciej



-- Yehuda

On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak m...@apple.com  
wrote:


On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:

Maybe this would be a good opportunity to revisit the utility of  
WebIDL in specifications (as formal specifications were re- 
examined for ES-Harmony). The WebIDL spec is pretty large, and I  
personally have found its use a confounding factor in  
understanding other specs (like HTML5).


Its utility is in providing a way to specify API behavior in a way  
that is consistent between specifications, language-independent,  
and reasonably concise. It's true that it adds an additional thing  
you have to learn. That's regrettable, but there are a lot of  
details that need to be specified to get interoperability. Pre- 
WebIDL specs such as DOM Level 2[1] left many details undefined,  
leading to problematic behavior differences among browsers and a  
need for mutual reverse-engineering.


Regards,
Maciej

[1] http://www.w3.org/TR/DOM-Level-2-Core/




-- Yehuda

On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich  
bren...@mozilla.com wrote:

On Sep 24, 2009, at 7:55 AM, Maciej Stachowiak wrote:

It seems like this is a Web IDL issue. I don't see any reason for  
Web IDL to move to ECMA. It is a nominally language-independent  
formalism that's being picked up by many W3C specs, and which  
happens to have ECMAScript as one of the target languages. Much of  
it is defined by Web compatibility constraints which would be  
outside the core expertise of TC39.


Some of us on TC39 have lots of Web compatibility experience :-P.



Probably the best thing to do is to provide detailed technical  
review of Web IDL via the W3C process.


Expertise on both sides of the artificial standards body divide  
may very well be needed. The rest of this message convinces me it  
is needed.


One problem with inviting review via the W3C process is getting  
attention and following too many firehose-like mailing lists. es-disc...@mozilla.org 
 is at most a garden hose, which is an advantage.


Another problem is that not all Ecma TC39 members are W3C members  
(their employers are not members, that is).


There are transparency problems on both sides, IMHO. People in  
dark-glass houses...




https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
and the rest of that thread

https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
(not the transactional behavior, which is out -- just the
interaction with Array's custom [[Put]]).

https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
 on an ArrayLike interface with references to DOM docs at the  
bottom


https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
 about a WebIDL float terminal value issue.

It seems like these are largely Web IDL issues (to the extent I  
can identify issues in the threads at all).


TC39 members, Mark Miller articulated this yesterday, hope to  
restrict host objects in future versions of the JavaScript  
standard from doing any nutty thing they like, possibly by  
collaborating with WebIDL standardizers so that instead of  
anything goes for host objects, we have only what WebIDL can  
express.


Catch-all magic where host object interfaces handle arbitrary  
property gets and puts are currently not implementable in ES --  
this may be possible in a future edition, but even then it will  
carry performance penalties and introduce analysis hazards. We  
hope to steer ES bindings for WebIDL-expressed interfaces away  
from catch-all patterns.


Beyond this tarpit, we're interested in the best way to linearize  
multiply-inherited WebIDL interfaces onto prototype chains, or  
whether to use prototype

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination



On Sep 24, 2009, at 2:16 PM, Sam Ruby wrote:


On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:


Any TC39 members whose employers can't join could perhaps become  
Invited
Experts to the W3C Web Applications Working Group, if that  
facilitates

review.


Unfortunately, no.  See #2 and #3 below:

 http://www.w3.org/2004/08/invexp.html


It depends on the nature of the employer, and the reason they are  
unable to join. Historically there have been Invited Experts in W3C  
Working Groups who are employed by such organizations as universities  
or small start-ups. We even have some in the HTML Working Group. So it  
would probably be more accurate to say it depends and that it may be  
subject to the judgment of the W3C Team.


Regards,
Maciej

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination



On Sep 24, 2009, at 2:37 PM, Sam Ruby wrote:


Maciej Stachowiak wrote:

On Sep 24, 2009, at 2:16 PM, Sam Ruby wrote:

On Sep 24, 2009, at 11:53 AM, Maciej Stachowiak wrote:


Any TC39 members whose employers can't join could perhaps become  
Invited
Experts to the W3C Web Applications Working Group, if that  
facilitates

review.


Unfortunately, no.  See #2 and #3 below:

http://www.w3.org/2004/08/invexp.html
It depends on the nature of the employer, and the reason they are  
unable to join. Historically there have been Invited Experts in W3C  
Working Groups who are employed by such organizations as  
universities or small start-ups. We even have some in the HTML  
Working Group. So it would probably be more accurate to say it  
depends and that it may be subject to the judgment of the W3C Team.


I've discussed the specific case with the W3C, and it is the case  
that in the judgment of the W3C Team, the answer in this specific  
case is no.


You, of course, are welcome to try again in the hopes of getting a  
different answer.


I didn't know that there was a specific case driving this concern. I  
thought this was a general worry about, e.g., university researchers.  
I would not ask the W3C Team to reconsider specific cases where they  
have already rendered a judgment.


Regards,
Maciej

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination



On Sep 24, 2009, at 5:44 PM, Yehuda Katz wrote:

That sounds reasonable. There are really two issues. One is that  
there are parts of WebIDL that are unused. Another is that the parts  
of the spec themselves are fairly arcane and very implementor- 
specific. Consider:


interface UndoManager {
  readonly attribute unsigned long length;
  getter any item(in unsigned long index);
  readonly attribute unsigned long position;
  unsigned long add(in any data, in DOMString title);
  void remove(in unsigned long index);
  void clearUndo();
  void clearRedo();
};

I almost forget that I'm looking at something most widely  
implemented in a dynamic language when I look at that. Since this is  
most likely to be implemented in terms of ECMAScript, why not  
provide an ECMAScript reference implementation?


These methods do things that can't actually be implemented in pure  
ECMAScript, since they need to tie into the browser implementation and  
system APIs. So a reference implementation in ECMAScript is not  
possible.


What this interface definition actually specifies is some constraints  
on how the implementation of this object is reflected to ECMAScript.  
For example, this method must convert its second parameter to a string  
using a particular algorithm, and the prose description of the  
method's behavior assumes that has been done, and the return value  
promises to be a positive integer:


unsigned long add(in any data, in DOMString title);

This method converts its one parameter to a number, and performs  
truncation and range checks according to some standard rules, and will  
for example raise an exception if a negative number is provided:


void remove(in unsigned long index);

It would be tedious to spell out all those details for every such  
method, either in prose or in ECMAScript code - that interface  
definition would be replaced by something 5-10 times as long.


Another thing to keep in mind - although ECMAScript is the primary  
target language for the IDL interfaces in Web technology  
specifications, it is quite common to expose these interfaces in Java,  
and is desirable for various applications to be able to provide them  
in languages such as Python, C++, Objective-C, and Ruby. Thus, we need  
a language-independent formalism to define the interfaces, even though  
the ECMAScript bindings are the most important.


And finally, even though the snippet of Web IDL you cited is very much  
aimed at authors, I think it's pretty easy to understand the practical  
upshot for ECMAScript programmers, without understanding the details  
of Web IDL. It's pretty clear what attributes and methods you can use,  
and what kind of parameters you should provide. For those who care  
about the full details, you only have to learn Web IDL once, and it's  
not a very big syntax. It's sort of like learning EBNF to understand  
grammar definitions. The extra conciseness is worth the cost of an  
extra formal syntax to learn, in my opinion.


Regards,
Maciej

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Maciej Stachowiak



On Sep 25, 2009, at 2:38 AM, Sam Ruby wrote:


Maciej Stachowiak wrote:

On Sep 24, 2009, at 5:44 PM, Yehuda Katz wrote:
That sounds reasonable. There are really two issues. One is that  
there are parts of WebIDL that are unused. Another is that the  
parts of the spec themselves are fairly arcane and very  
implementor-specific. Consider:


interface UndoManager {
 readonly attribute unsigned long length;
 getter any item(in unsigned long index);
 readonly attribute unsigned long position;
 unsigned long add(in any data, in DOMString title);
 void remove(in unsigned long index);
 void clearUndo();
 void clearRedo();
};

I almost forget that I'm looking at something most widely  
implemented in a dynamic language when I look at that. Since this  
is most likely to be implemented in terms of ECMAScript, why not  
provide an ECMAScript reference implementation?
These methods do things that can't actually be implemented in pure  
ECMAScript, since they need to tie into the browser implementation  
and system APIs. So a reference implementation in ECMAScript is not  
possible.


I'll accept that it is a true statement that in an pure ECMAScript  
implementation of these interfaces in Safari on Mac OSX such  
wouldn't be possible.


Alternate perspective, one that I believe more closely matches the  
view of TC39: one could image an operating system and browser  
implemented in either in ECMAScript or in a secure subset thereof.   
In such an environment it would be highly unfortunate if the the  
WebIDL for something as important as HTML5 and WebApps were written  
in such a way as to preclude the creation of a conforming ECMAScript  
implementation.


Unfortunately, this is the case. But in many cases this is due to  
legacy compatibility requirements combined with certain features that  
do not (yet) exist in ECMAScript. See below.


At this point, I'm not personally interested in discussions as to  
whether WebIDL is or is not the right way forward.  Anybody who  
wishes to invest their time in producing more useful documentation  
and/or reference implementations is not only welcome to do so, they  
are positively encouraged to do so.


Meanwhile, what we need is concrete bug reports of specific  
instances where the existing WebIDL description of key interfaces is  
done in a way that precludes a pure ECMAScript implementation of the  
function.


I think the main cases where this is true are interfaces with catchall  
getters and setters, or interfaces that are callable (but also have  
various methods and properties and are not Functions). I believe most  
of these are due to legacy compatibility constraints. Thus, ECMAScript  
will need to change to be able to plausibly implement equivalent  
interfaces. A change to Web IDL to match current ECMAScript  
capabilities would mean it can't actually describe the APIs that exist  
in browsers today, and such a description of these APIs would be,  
essentially, false. This seems like putting the cart before the horse.


Let me give a concrete example, the HTMLCollection interface from  
HTML5: http://dev.w3.org/html5/spec/Overview.html#htmlcollection-0.


This interface is defined to have getter properties which imply  
catchall getters for index and non-index properties. This is  
implemented by all existing browsers and is needed for compatibility  
with a lot of Web content. It is also required by DOM Level 2 HTML's  
ECMAScript bindings: http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html 
. The fact that ECMAScript 5 can't implement an interface that  
behaves like this is an ECMAScript issue, not an HTML issue, in my  
opinion, and one that will hopefully be fixed in future editions.


Now, it may be that some non-legacy APIs require special host object  
behavior that wouldn't otherwise be implicated by legacy APIs. If  
anyone identifies such APIs, then we can look at fixing them.


Regards,
Maciej

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

2009-09-25 Thread Maciej Stachowiak



On Sep 25, 2009, at 3:34 PM, Krzysztof Maczyński wrote:


Do we need a WindowProxy in the core language? I'm not sure, but if
not then there has to be some other way of specifying how |this| in
global code binds to the outer window rather than the inner (Ecma
global). We didn't try to make something up here for ES5.


ECMAScript could just allow host embeddings to make the outermost
scope chain entry be something other than the global object. The main
downside is that this is more loose than is needed and could
technically allow crazy unreasonable things. But it may not be
possible to fully specify the behavior at the ECMAScript level, since
it depends on the notion of navigation. There may be a way to provide
a more narrowly tailored hook.

Regards,
Maciej
ECMA-262 allows (in 15.1) the prototype of the global object to be  
anything (including a host object with catchall semantics, or with  
properties existing for all names, just with value undefined, custom  
[[Put]] and [[Get]], etc.). Would implementing WindowProxy on that  
object and Window on the global object solve the use cases?
Is there actually a comprehensive list of use cases for this  
splitting anywhere, to facilitate checking any potential solutions  
against them?


ECMAScript requires the outermost scope chain entry and the object  
that is used as this for global function calls to be the same  
object. But the scope chain entry cannot be directly observed, so the  
only observable difference is in property access behavior. Nothing  
requires this to be stable and consistent for a host object.


But ECMAScript doesn't have a way to distinguish normal property  
access from property access via lexical scoping. It's unclear whether  
you could say an object is actually the same but happens to give  
different answers for scope chain access and direct property access,  
and possibly even different answers depending on which scope chain it  
was found in. I would think that strains host object exemptions to the  
breaking point.


Regards,
Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 25, 2009, at 11:32 PM, Brendan Eich wrote:


On Sep 25, 2009, at 11:28 PM, Brendan Eich wrote:


We seem to agree, perhaps vehemently :-/.

One last time, for the record: it is a bug in ES specs that you  
can't follow th


Sorry, rogue cut before send. it's a bug in ES specs that you can't  
follow them in order to implement a web-compatible JS engine.


Although some of web-compatible JS really does belong in W3C  
specs, not ES specs, it's clear ES1 pretending there is only one  
global object did no one any favors. Ditto for execution model and  
(ultimately) split windows, as Hixie pointed out in raising the  
conflict between HTML5 and ES1-3 (and now ES5).


Just wanted to reassure you, since you seemed to think otherwise,  
that no one views it as a feature that ES specs don't specify  
enough. HTML4 specs didn't either. We're getting there.


That's right. ES3, HTML4 and DOM Level 2 were all missing many things  
needed to implement Web-compatible behavior, as well as having  
requirements that were in some cases contrary to real-world  
compatibility. Writing a new browser engine based on those specs  
required multiple years of trial and error and reverse engineering  
after implementing the spec behavior. Take it from me - that's what we  
had to do to make WebKit (even building on the foundation of KHTML 
+KJS, which had already done some of the reverse engineering).


ES5, HTML5, Web IDL and some of the Web Apps specs (like  
XMLHttpRequest and DOM3 Events) are huge steps forward on this front.  
They don't solve every problem, but they are massive improvements in  
getting the Web platform correctly specified.


Regards,
Maciej

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination



On Sep 26, 2009, at 12:20 AM, David-Sarah Hopwood wrote:


Maciej Stachowiak wrote:

I think there are two possible perspectives on what constitutes
magnify[ing] the problem or widening the gap

A) Any new kind of requirement for implementations of object  
interfaces

that can't be implemented in pure ECMAScript expands the scope of the
problem.
B) Any new interface that isn't implementable in ECMAScript widens  
the

gap, even if it is for a reason that also applies to legacy


My view is firmly B, for the reasons given below.


My view is A. That's why I pointed to legacy interfaces - if the
construct can't go away from APIs in general, but we wish to  
implement

all APIs in ECMAScript, then ultimately it is ECMAScript that must
change, so using the same construct again doesn't create a new  
problem.


Yes it does:

- In many cases, APIs are partially redundant, in such a way that
  developers can choose to avoid some of the legacy interfaces without
  any significant loss of functionality. By doing so, they can avoid  
the
  problems caused by clashes between names defined in HTML, and  
names of

  ECMAScript methods. If new APIs also use catch-alls, they are less
  likely to be able to do this.

- The potential name clashes created by catch-alls also create a  
forward

  compatibility issue: if a new method is added to an interface, it
  might clash with names used in existing HTML content. In the case of
  legacy interfaces, it is less likely that we want to add new methods
  to them, and so this forward compatibility issue is less of a  
problem.


It seems like these first two reasons are pragmatic concerns about  
fully general property access catchalls, which are independent of  
anyone's desire to implement the interfaces in ECMAScript. These  
arguments also do not apply to other kinds of extended host object  
behavior, such as array-like index access, or the fact that  
document.all compares as boolean false.




- Implementors of subsets in which the DOM APIs are tamed for  
security
  reasons can choose not to implement some APIs that are problematic  
for
  them to support; but if new APIs are equally problematic, they  
will be

  unable to provide access to that functionality.


I think trying to tame the DOM APIs is a quixotic task anyway.

A common example cited is to embedding a widget via direct DOM  
embedding in a safe way. Presumably safe means you have toprevent  
the widget reading or modifying the DOM outside its subtree, prevent  
executing JS outside the sandbox, and prevent displaying content  
outside its designated bounds. To achieve this, you have to restrict  
the behavior of nearly every single DOM method, often in extremely  
complicated ways that amount to reimplementing major portions of  
browser functionality.


Consider for example the setAttribute method on the Element interface.  
You have to intercept attempts to set the style attribute, parse the  
CSS being set, and make sure that the widget is not trying to use CSS  
positioning or overflow to display outside its bounds. You can't just  
forbid CSS styling entirely, because that makes it impossible to make  
a decent-looking widget. previousSibling, nextSibling, ownerDocument  
all have to be prevented from going outside the tree. Any method to  
find particular elements has to be essentially rewritten to prevent  
going outside the tree, even something as basic as  
document.getElementById(). Attempts to set the id attribute have to  
be intercepted and the id has to be silently rewritten if it clashes  
with an id used in the embedding content, so that getElementById()  
calls by the embedder aren't tricked into manipulating the embedded  
content. Timers have to be reimplemented to make sure their JavaScript  
is executed in the sandbox. Setting a href to a javascript: URL  
has to be prevented, unless you completely override the navigation  
behavior of a elements. Creating plugins or Java applets has to be  
prevented, since they can't be made to follow the security  
constraints. document.write() and innerHTML have to be intercepted,  
and the contents have to be parsed as HTML to prevent any forbidden  
constructs in the markup. This is just scratching the surface, and  
we've already found that CSS parsing, HTML parsing and DOM query  
methods will have to be reimplemented (from scratch, yet in a way that  
matches what the browser does) to make this work. Note that none of  
this complexity is imposed by exotic host object behaviors, it's all  
intrinsic to the way the Web platform works. Even considering the case  
of taming LocalStorage, the catchall behavior is the least of your  
worries.


The best way to serve this kind of use case is either an iframe with  
postMessage, or inventing an entirely new API for embedded content  
that doesn't even try to look anything like the DOM, and just exposes  
a carefully selected set of capabilities. I don't think our time is  
well spent trying

Re: WebIDL



On Sep 25, 2009, at 11:33 PM, Yehuda Katz wrote:


WebIDL, taken as a whole, make it very difficult for someone new to
the spec(s) to understand what's going on. I started, like a
reasonable person, by looking at the Window object. When looking at
it, I encountered a number of somewhat confusing constructs, like this
one. It is possible to have a long conversation where all of the
details are hashed out, but the reality is that the specs cannot be
easily understood without such a hashing.


Window probably has more bizarre legacy behavior than any other  
interface. It's probably not the best starting point for understanding.


Regards,
Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 26, 2009, at 8:28 AM, Allen Wirfs-Brock wrote:



No we are not.  This is exactly the heart of our concern. The WebIDL
ECMAScript binding is not simply a mapping of IDL interface onto
standard language features (such as is done for the Java binding).
While it has some of that it also defines an extended ECMAScrpt  
language

with new semantics. (and I understand this is mostly a reflection
of past (present?) practice of browser implementers).  Essentially,
the semantics of browser ECMAScript has been arbitrarily split into
two independently maintained standards.


Is there any concrete concern on this front other than property access  
catchalls?


Regards,
Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 26, 2009, at 3:13 PM, Allen Wirfs-Brock wrote:





From: Maciej Stachowiak [mailto:m...@apple.com]

On Sep 26, 2009, at 8:28 AM, Allen Wirfs-Brock wrote:

...

 Essentially,
the semantics of browser ECMAScript has been arbitrarily split  
into

two independently maintained standards.


Is there any concrete concern on this front other than property  
access catchalls?


Every place the WebIDL ECMAScript binding overrides an ECMAScript  
specification
internal method is a concern as these are special case extensions to  
the ECMAScript
semantics.  As language designers we need to understand if these  
special cases are
exemplars of general deficiencies in the language that should be  
addressed.


We have definitely identified catchall property access as such an  
area. Are there in fact any others? It's a lot more interesting to  
look at specific examples than to expound on the general principles.  
See below where I did some study to find other missing capabilities.


In particular  now that ES5 is finished, WebIDL has a richer  
language to bind to then
it had with ES3.  We need a WebIDL binding that maximizes use of ES5  
capabilities rather
than inventing non-standard (from an ES perspective) language  
extensions.


Updating WebIDL to use ES5 concepts would definitely be worthwhile. At  
the time Web IDL was started (early 2007 I think) this wasn't a  
practical option, but it is now. In particular, interfaces that don't  
have any unusual behavior could be defined as having getters and  
setters, and should not need to override internal properties at all.  
This would better highlight the capabilities that are needed to  
implement the Web platform, but which can't be expressed in the  
property descriptor formalism.


I expect there are relatiively few such capabilities, and little  
interest in depending on new ones, and therefore we do not really have  
a general ongoing problem of language design.


From a quick scan of WebIDL, I see the following:

1) Catchall getters, putters, deleters, definer.
   - Variants that can make the catchall check happen either before  
or after normal property lookup.

   - General string-based name access and index-only versions.
   - Note: I think catchall deleters are used only by Web Storage and  
not by other new or legacy interfaces.
2) Ability to support being called (via [[Call]]) without being a  
Function.
3) Ability to support being invoked a constructor (via [[Construct]])  
without being a Function.
4) Ability to support instanceof checking (via [[HasInstance]])  
without being a constructor (so myElement instanceof HTMLElement works).
5) Ability to have [[Construct]] do something different than [[Call]]  
instead of treating it as a [[Call]] with a freshly allocated Object  
passed as this.


Tentatively, I think all other semantics of Web IDL interfaces can be  
implemented in pure ES5.


Regards,
Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 26, 2009, at 3:58 PM, Cameron McCormack wrote:


Cameron McCormack:
Indeed, much of the custom [[Get]] etc. functionality can be  
turned into
ES5 meta-object stuff.  A pertinent question is then: should we  
change

Web IDL to specify an ES5 binding (and not ES3) at this point, given
that specs depending on it want to advance along the Rec track?


Mark S. Miller:
Since ES5 will be officially done well ahead of HTML5, I don't see  
why

not. But I do not know what your Rec track constraints imply.


For example, Selectors API is at Last Call and will soon be in  
Candidate

Recommendation.  I don’t think it can progress further than that until
its dependencies move forward.


Selectors can't progress to PR/REC until Web IDL is in at least CR  
state (only one difference in maturity level is allowed for  
dependencies). I think Web IDL can enter CR with ES5 as is, but it  
will be considered final as soon as it is published, which is likely  
to be before Web IDL is ready for Last Call. ECMA process does not  
have any states between the equivalent of W3C Working Draft and W3C  
REC (as far as I know). So I don't think this would create any  
problems for Selectors advancing, other than the time to do the rewrite.


On the substantive issue: I do think it would be good to convert Web  
IDL from ES3 formalisms to ES5 formalisms. While Oliver is right that  
ES5 has not yet been proven by interoperable implementations, and that  
some of its methods as defined have a hard time with host objects, I  
believe that the basic designs of ES5 property descriptors and ES5  
getters/setters are sound.


Regards,
Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 26, 2009, at 4:41 PM, Oliver Hunt wrote:

The specific problem is that host objects cannot necessarily match  
the semantics of ES5, and for that reason the interaction of host  
objects with the ES5 semantics is unclear.


I think mapping Web IDL behavior to ES5 property descriptors would  
help make this interaction more clear.


 There are additional concerns -- various es5 features expose the  
underlying implementation mechanisms of the binding -- for instance  
using get or set properties on a dom binding would require  
getOwnPropertyDescriptor to expose that implementation detail.


getOwnPropertyDescriptor risks leaking implementation details (or at  
least implementation differences) in any case. The options for Web IDL  
are:


1) Leave the results of getOwnPropertyDescriptor completely  
implementation-defined, so different implementations may return  
different values.
2) Require getOwnPropertyDescriptor to return specific results that  
expose host object properties as something other than getters or  
setters.
3) Require getOwnPropertyDescriptor to return specific results that  
expose host object properties as getters/setters.


I reluctantly conclude that #3 is best. #1 leaves behavior  
unspecified, this needlessly creates the potential for interop  
problems. #2 conflicts with the way some implementations implement  
their DOM bindings (e.g. Gecko), meaning extra work for them, and is  
outright unimplementable in pure ECMAScript. #3 conflicts with the way  
some implementations implement their DOM bindings (e.g. WebKit) and  
would mean extra work for them.


#3 seems like it has the weakest disadvantages, even though it means  
extra work for us.


However, if we want to allow implementation variance (i.e. policy #1),  
we could still use ES5 getters and setters as the formal model, but  
say that host objects implementations may override [[GetOwnProperty]]  
to give implementation-defined results for host attributes. This would  
change Web IDL from saying that host object implementations MUST  
override internal methods to saying they MAY.


Regard,
Maciej

Re: WebIDL



On Sep 26, 2009, at 3:30 PM, Cameron McCormack wrote:


Yehuda Katz:
Ha. Maybe it would be worth putting a note in HTML5.  
[Replaceable] is

a quirk of history. Do not over-attend to it.


Ian Hickson:
If we start calling out all the quirks of history in HTML5, we'd  
probably

end up doubling the size of the spec.


OTOH calling out features in Web IDL that exist solely for quirky
compatibility reasons, that would help to discourage their use in  
other

specs.


Calling these cases out in Web IDL (as opposed to HTML5) seems like a  
good idea.


Regards,
Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 26, 2009, at 5:20 PM, Allen Wirfs-Brock wrote:





-Original Message-
From: Maciej Stachowiak [mailto:m...@apple.com]

I expect there are relatiively few such capabilities, and little
interest in depending on new ones, and therefore we do not really  
have

a general ongoing problem of language design.



We have an ongoing problem of language design in that all new language
features must integrate with existing features. Combinatory feature
interactions is one of the larger challenges of language design.


From a quick scan of WebIDL, I see the following:

1) Catchall getters, putters, deleters, definer.
  - Variants that can make the catchall check happen either before
or after normal property lookup.
  - General string-based name access and index-only versions.
No comment, I need to come up to speed on the detailed semantic  
requirements


They are pretty similar to the way Array overrides  
[[DefineOwnProperty]] or the way String defines





  - Note: I think catchall deleters are used only by Web Storage and
not by other new or legacy interfaces.


Seems like a strong reason to change to the proposed API to  
eliminate the need for

a new ES language extension.


I previously argued for removing the need for catchall deleters from  
the Web Storage API (since nothing else requires , but other browser  
vendors (including  Mozilla) were happy with it, and I think now  
everyone (including I believe Microsoft) has implemented the spec  
behavior. See prior discussion thread here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014851.html 
.  At this point, since we have multiple deployed implementations of  
Web Storage, we'd have to investigate whether it's safe to remove this  
behavior without breaking content.





2) Ability to support being called (via [[Call]]) without being a
Function.


Not an issue with the core ES5 semantics.  Most ES3/5 section 15  
functions have this
characteristic. As long as such WebIDL objects are defined similarly  
to the built-in
function they too can have this characteristic. It may well be  
useful to introduce a
mechanism defining such pure functions in the language but it  
probably isn't necessary
to proceed with the WebIDL binding.  The important thing to try to  
avoid is specify

a custom [[Call]]


I tend to agree that this behavior (and the next 3) are not  
philosophically problematic, even though they cannot today be  
implemented in pure ECMAScript.






3) Ability to support being invoked a constructor (via [[Construct]])
without being a Function.


Essentially same as 2 although the standard [[Construct]] requires a  
[[Call]] so this

may need some more thought.


4) Ability to support instanceof checking (via [[HasInstance]])
without being a constructor (so myElement instanceof HTMLElement  
works).


Possibly the specification of the instanceof operator needs to be  
made extensible



5) Ability to have [[Construct]] do something different than [[Call]]
instead of treating it as a [[Call]] with a freshly allocated Object
passed as this.


Similar to 4 regarding extensibility.  At least one recent harmony  
strawman proposal is

moving in a direction that may be relevent to 4 and 5.
See http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_constructors


Interesting. This may provide a way to implement some of these  
behaviors in pure ECMAScript. The current proposal does allow  
[[Construct]] without [[Call]], but not [[Call]] and [[Construct]]  
that both exist but with different behavior.


Regards,
Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 26, 2009, at 8:05 PM, Brendan Eich wrote:


On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:


- Note: I think catchall deleters are used only by Web Storage and
not by other new or legacy interfaces.


Seems like a strong reason to change to the proposed API to  
eliminate the need for

a new ES language extension.


I previously argued for removing the need for catchall deleters  
from the Web Storage API (since nothing else requires , but other  
browser vendors (including  Mozilla) were happy with it,


(including Mozilla) and happy with it leave out some nuance:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014856.html

Robert O'Callahan here wrote If overloading delete is too quirky  
or too hard to implement, then it seems none of the other shorthands  
should be allowed either. His message adverted to the better course  
of methodical access instead of property access to Web Storage keyed  
values.


Alas Rob finally gave up at:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014868.html

I think the Web Storage key/value reflection as properties is a  
mistake. Sorry I wasn't reviewing it in time to say so. But it was  
obviously not a situation everyone was happy with, even ignoring  
the issue of delete.


I accept your corrections as to nuance. At the time I felt like I was  
fighting a losing battle. The real issue, though, is what to do going  
forward.





and I think now everyone (including I believe Microsoft) has  
implemented the spec behavior. See prior discussion thread here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-May/014851.html 
.  At this point, since we have multiple deployed implementations  
of Web Storage, we'd have to investigate whether it's safe to  
remove this behavior without breaking content.


We could try to remove it -- or (what is more likely to go down  
easily) we could add methods and let the property reflections  
wither, and vow to avoid repeating this mistake.


There are methods, but I'm not optimistic that they will cause  
property reflection to wither.


If the number of places in the Web platform that require custom delete  
behavior goes from 1 to 2, that's a lot less bad than going from 0 to  
1. So it won't accomplish much. However, I missed a spot and it looks  
like custom deleters are also used by the DOMStringMap interface,  
which is used to reflect data-* attributes. http://dev.w3.org/html5/spec/Overview.html#domstringmap-0 
 I don't think anyone has implemented that yet.


I believe we could get rid of custom deleters from the Web platform if  
Firefox and IE remove support for custom deleters in LocalStorage,  
refuse to add it back, and refuse to implement it for DOMStringMap. If  
that happened, I'm sure other browsers and the spec would follow suit.  
I don't think I can convince my colleagues to remove the behavior from  
WebKit if Gecko and Trident continue to support it.






2) Ability to support being called (via [[Call]]) without being a
Function.


Not an issue with the core ES5 semantics.  Most ES3/5 section 15  
functions have this
characteristic. As long as such WebIDL objects are defined  
similarly to the built-in
function they too can have this characteristic. It may well be  
useful to introduce a
mechanism defining such pure functions in the language but it  
probably isn't necessary
to proceed with the WebIDL binding.  The important thing to try to  
avoid is specify

a custom [[Call]]


I tend to agree that this behavior (and the next 3) are not  
philosophically problematic, even though they cannot today be  
implemented in pure ECMAScript.


What does typeof say for such a callable object?


I think it should probably say object, though that's not compatible  
with ES3 or current WebKit practice.




In what sense are any DOM methods required to be not Functions  
(native function objects) in the specs? In Netscape of old and  
Mozilla browsers since 1998, DOM methods are native function objects.


This is not an issue for DOM methods. It's an issue for interfaces  
such as HTMLCollection and HTMLFormElement that support indexing by  
function call syntax, for legacy compatibility reasons. Constructors  
like XMLHttpRequest, Option and Image also do not inherit from  
Function.prototype even though they are callable.


This seems winning since developers want not only sane typeof,  
but .apply/call/bind.


It's definitely winning, and it may be possible to apply it to global  
constructors that are also callable as a future improvement, but it's  
probably not possible to make HTMLCollection or HTMLFormElement  
inherit from the Function prototype, and I think it would not be  
desirable either.




We've talked on es-discuss about pure functions (ones without  
[[Construct]] and .prototype) before:


https://mail.mozilla.org/pipermail/es5-discuss/2009-July/002920.html

in case you missed the thread. Agreed it's not a big deal. We have a  
bugzilla.mozilla.org

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)



On Sep 27, 2009, at 12:30 AM, Brendan Eich wrote:


On Sep 26, 2009, at 11:28 PM, Maciej Stachowiak wrote:



What does typeof say for such a callable object?


I think it should probably say object, though that's not  
compatible with ES3 or current WebKit practice.


ES3 lets host objects choose function or object or any old  
string (Implementation-dependent).


ES5 says:

Object (native or host and does implement [[Call]])
 - function

Object (host and does not implement [[Call]])
 - Implementation-defined except may not be undefined, boolean,  
number, or string.


I think it may be a compatibility risk for HTMLCollection to report  
its type as function instead of object.





This is not an issue for DOM methods. It's an issue for interfaces  
such as HTMLCollection and HTMLFormElement that support indexing by  
function call syntax, for legacy compatibility reasons.  
Constructors like XMLHttpRequest, Option and Image also do not  
inherit from Function.prototype even though they are callable.


Right, thanks for clarifying that. DOM collection types, even if  
callable (VBScript was to blame) are not function objects, and DOM  
constructors, unlike chapter 15 built-in ES constructors, are not  
generally function objects.



This seems winning since developers want not only sane typeof,  
but .apply/call/bind.


It's definitely winning, and it may be possible to apply it to  
global constructors that are also callable as a future improvement,  
but it's probably not possible to make HTMLCollection or  
HTMLFormElement inherit from the Function prototype, and I think it  
would not be desirable either.


Why not for HTMLFormElement? Agree for HTMLCollection.


By HTMLFormElement I mean the actual instances that represent the  
form element in an HTML DOM, not the pseudo-constructor object named  
HTMLFormElement on the window object. HTML5 gives it callable  
indexing. It already inherits from HTMLElement (and Element and Node)  
so it's unclear how to stick Function into its prototype chain. And I  
don't think we want call(), apply() and bind() methods to start  
appearing on form elements.





Perhaps it's sufficient to provide an API for altering the [[Call]]  
and [[Construct]] behavior of an existing object without a first- 
class syntax, following in the spirit of defineOwnProperty().  
Something like foo.defineOperation(construct,  
funcToCallWhenConstructing). This would address all of points 2 to  
5, for ECMAScript implementations that wish to precisely replicate  
DOM behavior. This approach could also be used for index getters/ 
setters/has-testers, general catchall getters/setters/has-testers,  
removing either one of call or construct while retaining the other,  
making call and construct do different things, and perhaps other  
useses. And using a method instead of first-class syntax would let  
scripts feature-test for this capability.


See http://wiki.ecmascript.org/doku.php?id=strawman:catchalls but  
note objections there, as well as some alternatives discussed in es-disc...@mozilla.org 
.


Thanks for the reference. That does look similar to my suggestion.  
However, it looks like the invoke and construct methods there are  
intended for calling a property of the object (or invoking it as a  
constructor), rather than for applying call or construct to the object  
itself.




A MOP for catchalls that stratifies the hooks into mirage (by  
analogy to mirror-based reflection) objects may be forthcoming;  
we'll see (I'll let the experts say more). A dark horse, at this  
point, but hey, those other horses made it out of the barn ;-).


For simple things like non-constructor functions one might prefer a  
declarative form. As an implementor and a developer, I would --  
mutation is a bitch to optimize in a VM, and to contain in one's  
user code. Also the meta-programming API seems likely to be more  
verbose than the (still elusive, but stipulate that it must be  
concise) hypothetical declarative syntax.


Sure - one way a MOP approach helps is by moving past debates about  
the most elegant syntax, by having unapologetically inelegant syntax.  
Then maybe once the capability is there, someone can invent good  
syntax later.





Ye olde Image and Option, at least, act like most built-in  
constructors by constructing when called, at least in Gecko and I  
think IE -- but not in WebKit (I just tested).


My testing seems to indicate not in IE. Likewise for  
XMLHttpRequest. We should probably specify one way or the other  
whether these are callable and stick to it. I am indifferent as to  
which behavior we standardize on.


Me too, except if I had to do it all over again I would have worked  
harder to make function-ness orthogonal to prototype, a mixin if you  
will.


I wish functions and constructors were different kinds of things. I'm  
not sure if that's the same kind of idea you're talking about.



At this point,

http://wiki.ecmascript.org/doku.php?id

Re: Cross posting madness must stop.

On Sep 27, 2009, at 12:35 PM, Mark S. Miller wrote:

Comparing https://mail.mozilla.org/pipermail/es-discuss/2009-September/
with http://lists.w3.org/Archives/Public/public-webapps/
2009JulSep/ and http://lists.w3.org/Archives/Public/public-html/2009Sep/
shows why this cross posting madness must stop. Some messages in
this thread are only posted to one side of the W3C / ECMA divide,
indicating that some posters only subscribe on one side. These
posters are mutually opaque to the posters subscribing only on the
other side of the divide, leading to a fragmented conversation. For
example, the excellent posts by David-Sarah Hopwood https://mail.mozilla.org/pipermail/es-discuss/2009-September/author.html#9879
have generally gotten responses only from the ECMA side. Some
later messages from the W3C side seem to have missed some of his
points.

Rather than create a list specific to the WebIDL-ES5 language
bindings, I suggest an open public list for discussions likely to be
of interest to both communities. Are there any territoriality issues
one should be aware of before creating such a list?

Cross posting isn't great, but a brand new list will be missing many
people with an interest in the topic for a while until it ramps up. In
the meantime, I think both es-discuss and public-webapps are open for
anyone to subscribe to (public-html ironically requires more hoops,
since you have to be part of a W3C Member organization or become an
invited expert). I'm subscribed to all 3 lists so my only annoyance is
getting multiple copies of every email.

My point is this: we're having a really fruitful discussion right now,
one that was long overdue. While there are some mechanically bad
things about the way we're doing it, I'd like to avoid killing the
momentum. So let's keep talking this way, as long as we have useful
things to say, and until we can create a better mechanism.

For the slightly longer term: I think a list for general ECMA/W3C
scripting coordination is a good idea. But I'd also like that to be
the main list we use for the development of Web IDL, since any
discussion about WebIDL is likely to be of cross-functional interest.
And I don't want to make people subscribe to two new lists. Whether we
call it public-webidl or public-scripting-coordination doesn't matter
that much to me. Preference? W3C can probably set up such a list in
fairly short order, but likely not until Monday.

Regards,
Maciej

Re: Web IDL Garden Hose



On Sep 27, 2009, at 11:14 AM, Brendan Eich wrote:


On Sep 27, 2009, at 10:41 AM, David-Sarah Hopwood wrote:


Brendan Eich wrote:

On Sep 26, 2009, at 6:08 PM, Maciej Stachowiak wrote:


This may provide a way to implement some of these behaviors in pure
ECMAScript. The current proposal does allow [[Construct]] without
[[Call]], but not [[Call]] and [[Construct]] that both exist but  
with

different behavior.


Date needs the latter.


That can already be done in ES5. As I've previously suggested:

function Date(yearOrValue, month, date, hours, minutes, seconds,  
ms) {

  use strict;
  if (this === undefined) {
return TimeToString(CurrentTime());
  }
  // constructor behaviour
  ...
}


Of course, a variation on the idiom.

This is similar to what many implementations do too, rather than the  
implementation providing analogues of [[Call]] and [[Construct]]  
internal method on a non-function Date object. It works for Boolean,  
Number, String, and RegExp too.


But it is just a bit unsightly!


Will this do the right thing if you explicitly bind Date to a this  
value, for example, by calling it as window.Date(), or using call,  
apply, or function.bind, or by storing Date as the property of another  
random object?


Regards,
Maciej

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)