Re: Exposing structured clone as an API?

[Brendan Eich]

Step where you need to, to avoid falling over :-P.

The problems with generalized/extensible clone are clear but we have 
structured clone already. It is based on a hardcoded type-case 
statement. It could be improved a bit without trying to solve all 
possible problems, IMHO.


/be

Anne van Kesteren wrote:

On Fri, Apr 24, 2015 at 3:13 PM, Joshua Bell  wrote:

>  If we're not dragging in the notion of extensibility, is there complication?


I would be fine with adding an API without extensibility. I was just
afraid we might step on TC39's toes, but maybe since they're not
helping out with structured clones that's okay?

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

[Brendan Eich]

Hang on a sec before going off to a private or single-vendor thread 
because you think I sent you packing on topics that are of interest (as 
opposed to "Thread-Safe DOM").


I'm sorry I missed Travis's mail in my Inbox, but I see it now in the 
archives. The topics listed at the link he cites *are* interesting to 
many folks here, even if public-webapps may not always be the best list:


-

IRC log: http://www.w3.org/2014/10/29-parallel-irc

See also: Mohammad (Moh) Reza Haghighat's presentation on parallelism in 
the 29 October 2014 Anniversary Symposium talks


We covered three main potential areas for parallelism:

1. Find additional isolated areas of the web platform to enable 
parallelism. We noted Canvas Contexts that can migrate to workers to 
enable parallelism. Initial thoughts around UIWorkers are brewing for 
handling scrolling effects. Audio Workers are already being developed 
with specific real-time requirements. What additional features can be 
made faster by moving them off to workers?


2. "Shared memory" models. This seems to require an investment in the 
JavaScript object primitives to enable multiple threaded access to 
object dictionaries that offer robust protections around multi-write 
scenarios for properties.


3. Isolation boundaries for DOM access. We realized we needed to find an 
appropriate place to provide isolation such that DOM accesses could be 
"assigned" to a parallelizable JS engine. Based on discussion it sounded 
like element sub-trees wouldn't be possible to isolate, but that 
documents might be. Iframes of different origins may already be 
parallelized in some browsers.



-

Mozilla people have done work in all three areas, collaborating with 
Intel and Google people at least. Ongoing work continues as far as I 
know. Again, some of it may be better done in groups other than 
public-webapps. I cited roc's blog post about custom view scrolling, 
which seems to fall under Travis's (1) above.


Please don't feel rejected about any of these work items.

/be




Marc Fawzi <mailto:marc.fa...@gmail.com>
February 13, 2015 at 12:45 PM
Travis,

That would be awesome.

I will go over that link and hopefully have starting points for the 
discussion.


My day job actually allows me to dedicate time to experimentation 
(hence the ClojureScript stuff), so if you have any private branches 
of IE with latest DOM experiments, I'd be very happy to explore any 
new potential or new efficiency that your ideas may give us! I'm very 
keen on that, too.


Off list seems to be best here..

Thank you Travis. I really appreciate being able to communicate freely 
about ideas.


Marc


Boris Zbarsky <mailto:bzbar...@mit.edu>
February 11, 2015 at 12:33 PM
On 2/11/15 3:04 PM, Brendan Eich wrote:

If you want multi-threaded DOM access, then again based on all that I
know about the three open source browser engines in the field, I do not
see any implementor taking the huge bug-risk and opportunity-cost and
(mainly) performance-regression hit of adding barriers and other
synchronization devices all over their DOM code. Only the Servo project,
which is all about safety with maximal hardware parallelism, might get
to the promised land you seek (even that's not clear yet).


A good start is defining terms.  What do we mean by "multi-threaded 
DOM access"?


If we mean "concurrent access to the same DOM objects from both a 
window and a worker, or multiple workers", then I think that's a no-go 
in Servo as well, and not worth trying to design for: it would 
introduce a lot of spec and implementation complexity that I don't 
think is warranted by the use cases I've seen.


If we mean the much more modest "have a DOM implementation available 
in workers" then that might be viable.  Even _that_ is pretty hard to 
do in Gecko, at least, because there is various global state (caches 
of various sorts) that the DOM uses that would need to either move 
into TLS or become threadsafe in some form or something...  Again, 
various specs (mostly DOM and HTML) would need to be gone over very 
carefully to make sure they're not making assumptions about the 
availability of such global shared state.



We should add lighter-weight workers and immutable data structures


I should note that even some things that could be immutable might 
involved a shared cache in current implementations (e.g. to speed up 
sequential indexed access into a child list implemented as a linked 
list)...  Obviously that sort of thing can be changed, but your bigger 
point that there is a lot of risk to doing that in existing 
implementations remains.


-Boris

Brendan Eich <mailto:bren...@secure.meer.net>
February 11, 2015 at 12:04 PM


Sorry, I was too grumpy -- my apologies.

I don't see much ground for progress in this whole thread or the 
sub-thread you started.


If we&

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

[Brendan Eich]

Brendan Eich wrote:

over-the-top work


Apologies if this overloaded trope is confusing without more context -- 
it could mean "wildly excessive", or doing what soldiers in trenches did 
in WWI when the whistle blew (see 
https://www.youtube.com/watch?v=fssPqRWx9U0 :-/), but I meant "build on 
top of JS and the DOM" (even WebGL requires a bit of DOM for the canvas 
bit).


/be

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

[Brendan Eich]

Aryeh Gregor wrote:

This is all horrible, but that's life.


Indeed, nature is nasty. Search for "sacculina carcini life cycle" for 
but one example. The Web and the Internet are evolving systems with some 
parallels and analogies to biological evolution. See 
http://www.cc.gatech.edu/~dovrolis/ for more on this, if you are 
interested. Nothing like _Sacculina_ yet, luckily!


/be

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

[Brendan Eich]

Marc Fawzi wrote:

This guy here is bypassing the DOM and using WebGL for user interfaces

https://github.com/onejs/onejs

He even has a demo, with no event handling other than arrow keys at 
this point, and as the author admits ugly graphics, but with projects 
like React-Canvas (forget the React part, focus on Canvas UIs) and 
attempts like these it looks like the way of the future is to relegate 
the DOM to old boring business apps and throw more creative energy at 
things like WebGL UIToolKit (the idea that guy is pursuing)


I know Rik and keep in touch. OneJS is the kind of over-the-top work 
(not changing the DOM in-situ) that I recommended previously, in 
addition to incremental Web evolution. So once again, I'm not sure we 
disagree, but I am pretty sure your posts are misdirected to this list. 
Philosophizing about backward compatibility painting the Web into 
corners that kill it don't really move anything forward here.


There is a gap to fill with respect to the GPU, which WebGL-based 
toolkits won't bridge. I think Rik would agree that we can't replace the 
web with raw JS+WebGL. Meanwhile, since the first iPhone, the major 
engines have all offloaded parts of their CSS rendering to the GPU 
(ideally with a big shared texture memory, bigger than the display 
viewport), in order to use a separate thread from the main UI event loop 
thread, for 60fps touch response.


Of course the CPUs (multicore + SIMD) need to be used, so we don't want 
to marry a paritcular processing unit, or (worse) one GPU 
microarchitecture. Standards and even languages/toolkits (one.js is 
young) need to mature and abstract enough over hardware variation to be 
worth their weight -- but not so much they collapse like all the big OOP 
skycastles of the Java UI toolkit era have.


The more we can do with incremental standards to expose this OMTC/A 
CPU+GPU-based computation in first class ways on the Web, the less 
anyone will have to make a "old wolf or new tiger" decision between Web 
and non-Web approaches.


One concrete example: custom view scrolling. See

http://robert.ocallahan.org/2014/07/implementing-scroll-animations-using.html

If we can focus on these sorts of proposals and not "thread-safe DOM" or 
will-backward-compat-kill-the-Web imponderables, we'll get somewhere 
better, sooner.


/be

P.S. Meanwhile, are we done (for now) with deprecate-sync-XHR angst, and 
no browser actually plans to remove it? Not directed at Marc, rather my 
cc: list browser buddies. :-P

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

[Brendan Eich]

Marc Fawzi wrote:

<<
even if the DOM must remain a single-threaded and truly 
lock/barrier/fence-free data structure, what you are reaching for is 
doable now, with some help from standards bodies. ***But not by vague 
blather***

>>


Sorry, I was too grumpy -- my apologies.

I don't see much ground for progress in this whole thread or the 
sub-thread you started.


If we're talking about sync XHR, I gave my informed opinion that 
deprecating it is empty talk if actually obsoleting by whichever browser 
takes the first hit inevitably leads to market share loss or (before 
that) developers screaming enough to get the CEO's attention. We will 
simply waste a lot of time and energy (we already are) arguing and 
hollering for and against deprecation, without any definite hope of 
obsolescence.


If you want multi-threaded DOM access, then again based on all that I 
know about the three open source browser engines in the field, I do not 
see any implementor taking the huge bug-risk and opportunity-cost and 
(mainly) performance-regression hit of adding barriers and other 
synchronization devices all over their DOM code. Only the Servo project, 
which is all about safety with maximal hardware parallelism, might get 
to the promised land you seek (even that's not clear yet).


Doing "over the top" JS libraries/toolchains such as React is excellent, 
I support it. But it does not share mutable or immutable state across 
threads. JS is still single-threaded, event loop concurrency with 
mutable state, in its execution model. This execution model was born and 
co-evolved with the DOM 20 years ago (I'm to blame). It can't be changed 
backward-compatibly and no one will break the Web.


We should add lighter-weight workers and immutable data structures and 
other such things, and these are on the "Harmony" agenda with the JS 
standards body. We might even find race-confined ways to run asm.js code 
on multiple workers with shared memory in an ArrayBuffer -- that's an 
area of active research. But none of these things is anything near to 
what you described in the forked subject line: "Thread-Safe DOM".


I'll leave it at this.I invite others from Mozilla, Google, Apple, and 
MS to speak up if they disagree.


/be

Re: do not deprecate synchronous XMLHttpRequest

[Brendan Eich]

Marc Fawzi wrote:

I've recently started using something called an atom in ClojureScript and it is described 
as a mutable reference to an immutable value. It holds the state for the app and can be 
"safely mutated" by multiple components, and has an interesting thing called a 
cursor. It is lock free but synchronous. I think I understand it to some degree.


The win there is the mutations are local to the clients of the atom, but 
the underlying data structure it reflects is immutable. The DOM is not 
immutable and must not be for backward compatibility.



I don't understand the implementation of the DOM but why couldn't we have a 
representation of it that acted like the atom in clojure and then write the 
diff to the actual DOM.


Because browsers don't work that way. I wish they did, but they can't 
afford to stop the world, reimplement, optimize (if possible -- they 
will probably see regressions that are both hard to fix, and that hurt 
them in the market), and then restart the world.



Is that what React does with I virtual DOM? No idea but I wasn't dropping 
words, I was describing what was explained to me about the atom in clojure and 
I saw parallels and possibility of something similar in JS to manage the DOM.


I'm a big React fan. But it can virtualize the DOM using JS objects and 
do diffing/patching, without having to jack up the browsers (all of 
them; note "stop the world" above), rewrite their DOMs to match, and get 
them optimized and running again.



With all the brains in this place are you telling me flat out that it is 
impossible to have a version of the DOM (call it virtual or atomic DOM) that 
could be manipulated from web workers?


I'm not. People are doing this. My explicit point in a previous reply 
was that you don't need public-webapps or browser vendors to agree on 
doing this in full to start, and what you do in JS can inform smaller, 
easier steps in the standards body. One such step would be a way to do 
sync i/o from workers. Clear?



Also I was mentioning immutable and transient types because they are so 
necessary to performant functional programming, as I understand it.


Sure, but we're back to motherhood-and-apple-pie rhetoric now.


Again the clojure atom is lock free and synchronous and is mutable and thread 
safe. Why couldn't something like that act as a layer to hold DOM state.


First, lock-free data structures are not free. They require a memory 
barrier or fence, e.g., cmpxchg on Intel. Study this before endorsing it 
as a free lunch. Competing browsers will not add such overhead to their 
DOMs right now.


Second, even if the DOM must remain a single-threaded and truly 
lock/barrier/fence-free data structure, what you are reaching for is 
doable now, with some help from standards bodies. But not by vague 
blather, and nothing to do with sync XHR, to get back on topic.



  Maybe that's how React's virtual DOM works? I don't know but I find the idea 
behind the atom very intriguing and not sure why it wouldn't be applicable to 
making the DOM thread safe. What do the biggest brains in the room think? 
That's all. A discussion. If people leave the list because of it then that's 
their right but it is a human right to speak ones mind as long as the speech is 
not demeaning or otherwise hurtful.


I think you're on the wrong list. This isn't the place for vague albeit 
well-intentioned -- but as you allow above, uninformed ("I don't know") 
-- speculations and hopes.



I really don't understand the arrogance here.


Cut it out, or I'll cite your faux-humility as tit-for-tat. We need to 
be serious, well-informed, and concrete here. No speculations based on 
free-lunch (!= lock-free) myths.


As for sync XHR, I agree with you (I think! I may be misremembering your 
position) that compatibility trumps intentions on the Web. This favors 
the React "built it in JS on top" approach, with future DOM (and other, 
e.g. WebComponents) standards following fast.


/be

Re: do not deprecate synchronous XMLHttpRequest

[Brendan Eich]

Your message to which I replied is not cited accurately below by you. 
The text you wrote is here, in between """ lines:


"""
How about a thread-safe but lock-free version of the DOM based on 
something like Clojure's atom? So we can manipulate the DOM from web 
workers? With cursor support?


How about immutable data structures for side-effect-free functional 
programming?


How about  Will think of more
"""

This message text is exactly what I wrote my reply against.

It's useless; sorry, this happens, but don't make a habit of it, or most 
practitioners will unsubscribe to public-webapps. The DOM is a mutable 
single-threaded store, so there's no lock-free version possible. You'd 
have snapshots, with some cost in the snapshotting mechanism, at best. 
Then, you wouldn't be able to "manipulate" in any shared-state sense of 
that word, the DOM from workers.


Sorry, but that's the way things are. Dropping words like immutable and 
lock-free doesn't help. That, plus a lot of attitude about deprecating 
sync XHR (on all sides; I'm not in favor of useless deprecation, myself 
-- good luck to browsers who "go first" on actually *removing* sync XHR 
support), adds up to noise in this list. What good purpose does noise to 
signal serve?


/be


Marc Fawzi <mailto:marc.fa...@gmail.com>
February 10, 2015 at 6:24 PM
What? a good cop bad cop routine? Jonas asks for a constructive 
contribution or ideas for missing functionality in the web platform 
and the inventor of JS honors me with a condescending response, as if ...


What the hey! Mr. Eich!

I guess this explains the origin of JS: a knee jerk reaction to 
then-trendy ideas...


That's not the way to go about all inclusive debate.

Thank you.

Sent from my iPhone


Brendan Eich <mailto:bren...@secure.meer.net>
February 10, 2015 at 5:44 PM
Please stop overloading public-webapps with idle chatter.

React and things like it or based on it are going strong. Work there, 
above the standards. De-jure standardization will follow, and we'll 
all be better off for that order of work.


/be



Marc Fawzi <mailto:marc.fa...@gmail.com>
February 10, 2015 at 12:51 PM
i agree that it's not a democratic process and even though some 
W3C/TAG people will engage you every now and then the end result is 
the browser vendors and even companies like Akamai have more say than 
the users and developers. It's a classic top-down system, but at least 
most debates and discussions happen over open-access mailing lists.


I wish there was an app like Hacker News where browser vendors via 
W3C, TAG, webapps etc engage users and developers in discussions and 
use up/down votes to tell what matters most to users and developers.


But design by committee is really hard and sub-optimal, and you need a 
group of true and tried experts (open minded ones) to call the shots 
on various technical aspects.

Re: do not deprecate synchronous XMLHttpRequest

[Brendan Eich]

Please stop overloading public-webapps with idle chatter.

React and things like it or based on it are going strong. Work there, 
above the standards. De-jure standardization will follow, and we'll all 
be better off for that order of work.


/be

Marc Fawzi wrote:

How about a thread-safe but lock-free version of the DOM based on something 
like Clojure's atom? So we can manipulate the DOM from web workers? With cursor 
support?

How about immutable data structures for side-effect-free functional programming?

How about  Will think of more

Re: HTML imports in Firefox

[Brendan Eich]

Ashley Gullen wrote:
On 15 December 2014 at 19:09, Boris Zbarsky > wrote:



But more to the point, we're not shipping imports because we've
gotten feedback from a number of people that imports are not
solving the problems they actually need solved.  We'd prefer to
not ship imports and then need to ship yet another HTML import
system that solves those problems.


Well, imports work better for us than Javascript modules, for the 
reasons I gave. I hadn't given any feedback because everything looked 
great with HTML imports and I was simply waiting for it to arrive in 
browsers. Maybe the process biases feedback towards the negative?


No, rather a Chrome-only writte-in-C++  "specification by 
implementation" is, however nice you find it, underspecified.


I guess you never hear the chorus of "cool, can't wait!" from everyone 
looking forwards to it?


Let's work through interop issues with the polyfill, first, please.

/be

Re: New approach to activities/intents

[Brendan Eich]

Dimitri Glazkov wrote:
I thought about this a bit and realized that we first need to have a 
common criteria to evaluate whether we even need something like Tubes. 
That should be done before we get into mechanics of the solution. I 
apologize for jumping the gun. And I apologize even more to poor op 
whose conversation we hijacked.


So I came up with the following Capability Availability Success Criteria:

Given any capability on a modern computing device and a developer who 
wants to use it, what is a) the acceptable delay between when this 
capability becomes available on the web platform vs. first being 
available on a native platform, and b) the likelihood that this 
capability will ever be available on the web platform.


If we're aiming at "years, not months", and "60-80%", then we're 
already successful.


If we're hoping to hit "weeks, not months" and "100%", we need 
something like Tubes.


If it's something in between, maybe there are other options.


There are definitely other options. I think you've backed yourself into 
a dialectical corner. MessagePorts are not the primitive droids we're 
looking for! For one, JS SIMD cannot and should not use them. Even 
witha  sync-on-this-async-API-call general API, they are not the right 
droid.


I see roc has replied (we are not communicating via back-channels) so 
I'll stop here.


The actor model is beautiful and in part true, but it's not workers or 
MessagePorts, and it's not the right droid. Even if we add actors to the 
web platform, we will need to make particular, non-actor, synchronous 
API additions. These require careful design and (multiple browser) 
implementation with web developer feedback validation. Sorry, no easy 
answers. I do not think we need weeks not months, in any event (as noted 
vs. native stacks). We need intentional design with user (web dev) testing.


/be

Re: New approach to activities/intents

[Brendan Eich]

Dimitri Glazkov wrote:
Domenic's question still needs addressing separately, but just a quick 
response here -- the API roc described there is different. Tubes are 
just like talking to a worker or any MessagePort. There is no extra 
API surface emerging from getContext-like function call.


Any getContext or postMessage protocol is inherently not 
object-detectable, at least not at the string-keyed level.


In principal, as bz said, the tension between extensions and standards 
motivates supporting extensions, and I share your desire to support 
experimentation so long as it is consensus-oriented. We want to avoid 
overlarge jumps by one proprietor, who both risks failing to bring along 
competitors step by step, and seeming to abuse any market power it may 
possess.


So we want to support extension, extensibility, in ways that don't lead 
to bad game-theoretic and real-world outcomes, e.g. ActiveX PKI in 
Korea. There's no silver bullet or algorithm to do this, but API style 
matters (object detection vs. non-detection; gentle-peoples' agreements 
about how proprietary/particular an API to try).


The JS SIMD work definitely experiences this tension. Do we want a union 
of all (SSE, NEON, AVX2) vector instructions? Intersection may be too 
small, and emulation may be too slow to be worth using. The 
http://github.com/johnmccutchan/ecmascript_simd issues cover this well, 
and show good particularized thinking.


To particularize without object detection is hard.

In any event, IMHO native stacks are not killing the Web, nor are native 
stacks evolving willy-nilly on random and arbitrarily rapid schedules or 
via message-based API settings. Apple and Android are at most annual 
big-release OSes, e.g. I welcome counterexamples.


Sorry to be skeptical. Object detection, extensible-web-manifesto 
low-level APIs, avoiding indefinitely scoped or "lifetime" proprietary 
extension mechanisms in favor of incrementalism, all seem better to me.


/be

Re: New approach to activities/intents

[Brendan Eich]

Right.

Didn't we have a problem with Canvas's string-based getContext already?

http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html

/be


Domenic Denicola 
November 10, 2014 at 6:14 PM
From: Dimitri Glazkov [mailto:dglaz...@google.com]


Can you help us understand the advantages of a string-based 
proprietary APIs over a functions-and-objects proprietary APIs? We've 
had the latter for many years with vendor prefixes, so what are the 
advantages of putting them behind navigator.connect?


navigator.connect seems great just for talking to foreign service 
workers (in fact it can be the basis for a very general and powerful 
intents system). But from what I can understand it's serving two 
masters: talking to service workers built on standards that run in any 
browser, and also talking to virtual "service workers" that implement 
proprietary string-based APIs using "URLs" that only work in certain 
browsers. I don't understand how these are connected... Hope you can 
help me out there :)


Dimitri Glazkov 
November 10, 2014 at 12:45 PM
On Mon, Nov 10, 2014 at 1:38 AM, Anne van Kesteren > wrote:


On Fri, Nov 7, 2014 at 7:01 PM, Dimitri Glazkov
mailto:dglaz...@google.com>> wrote:
> FWIW, I think we should be concentrating on something like the
Tubes (aka
> navigator.connect): https://github.com/dglazkov/tubes
>
> It is hard to impossible to get these types APIs right on the
first try.
> That's why we need to create a clearinghouse for capability
experiments and
> be data-driven in designing the right API.

It's still not clear to me what the advantage is of creating a
framework for designing proprietary APIs.


If we don't do something like this as a platform, we'd be always 
lagging behind. Many new ideas start as proprietary. It takes time for 
these ideas to take shape and travel toward larger acceptance -- or 
die.  Instead of shunning these ideas until they mature -- and thus 
effectively shut the door to any innovation, we should embrace them 
and give them a place in the platform.


Take 
http://www.intel.com/content/www/us/en/architecture-and-technology/realsense-overview.html 
as an example. It's unclear whether this will lead to anything great. 
It's even less clear what the Web platform API should look like, or 
whether this will every result on a standard API. However, if we wait 
until clarity, we as a platform would lose the ability to participate 
in the virtuous innovation cycle and, as a result, lose more developer 
mindshare.


FWIW, it is perfectly reasonable for us to admit that we as a platform 
aim to always be years behind other platforms. But then we should make 
this clear and communicate it to developers who keep trying to not 
give up on the Web as a viable modern development platform.


:DG<



--
https://annevankesteren.nl/


Anne van Kesteren 
November 10, 2014 at 4:38 AM

It's still not clear to me what the advantage is of creating a
framework for designing proprietary APIs.


Dimitri Glazkov 
November 7, 2014 at 1:01 PM
FWIW, I think we should be concentrating on something like the Tubes 
(aka navigator.connect): https://github.com/dglazkov/tubes


It is hard to impossible to get these types APIs right on the first 
try. That's why we need to create a clearinghouse for capability 
experiments and be data-driven in designing the right API.


:DG<


Mounir Lamouri 
November 7, 2014 at 11:57 AM
(I realise that my reply went to public-webapps instead of whatwg, not
sure why. I will blame my email client :))

On Fri, 7 Nov 2014, at 20:36, Anne van Kesteren wrote:

Wouldn't be worth experimenting first with a list of predefined share
endpoints (that you anyway might want to have) and see if the feature is
actually something that users are looking for?

We have something like that in Firefox Nightly. Apple ships something
similar in Safari. Both can be extended through proprietary APIs.


I think it would be great if Mozilla could keep track of the usage of
this feature and share that data.


Furthermore, wouldn't
that make sense to have a similar mechanism than Open Search and have a
way for a website to advertise its share endpoint(s)? Maybe the Manifest
could be a good use for that. Generally speaking, I see a lot of common
aspects between Open Search and this proposal.

Maybe. It would be even less flexible and depend even more on user
interface innovation from the user agent.


I don't think the issue here is flexibility. It's extensibility. You
want website to be able to advertise themselves in that list. Thus,
websites will only try to do so if they see a benefit in doing that, in
other words, if that feature is actually used by Firefox users.

As a side note, I don't think that innovation always need to come from
new APIs. That feature sounds like

Re: =[xhr]

[Brendan Eich]

David Rajchenbach-Teller wrote:

Clearly, it would require big changes, although compiling to return
Promise and using Task.js + yield at call sites would probably be much
simpler than CPS conversion.


All call sites, every last Java method => JS function call? That means 
every single function becomes a generate, all functions use yield and so 
become generator functions, all calls construct a generator which must 
have .next() called to get it started. The performance is not going to 
be tolerable.


This vague suggestion has come  up with Emscripten re: sync APIs for 
workers, and it's a bogus hand-wave. Please don't suggest it as a 
solution and then make definite plans to reject sync APIs in workers or 
schedule removal of XHR's async=false mode on a date certain!


/be

Re: =[xhr]

[Brendan Eich]

David Rajchenbach-Teller wrote:

it would require changes to Java2Script.


Big changes -- CPS conversion, compiling with continuations. This would 
require identifying all the potential blocking points. It's not clear 
anyone will do it, even if it is feasible (thanks to Java's static types 
and more analyzable scope rules). Don't hold your breath.


Is Java2Script open source? I couldn't find a repo at a quick search.

/be

Re: {Spam?} Re: {Spam?} Re: [xhr]

[Brendan Eich]

Brendan Eich wrote:
In this light, WHATWG should avoid making indefinite-timescale, 
over-ambitious assertions. The W3C was rightly faulted when we founded 
the WHATWG for doing so.


My apologies for a minor error: Anne informs me off-list that "W3C" 
(who?) added the warning. Not that it should matter for advocates of the 
warning where it shows up -- and it's in the WHATWG copy of the spec too 
(http://xhr.spec.whatwg.org/).


My point remains independent of "group blame": the warning is pretty 
much all a folly. All it has demonstrably done is to worry folks like 
Robert and then waste our time on this thread. I want those minutes of 
my life back.


/be

Re: {Spam?} Re: [xhr]

[Brendan Eich]

cha...@yandex-team.ru wrote:

Sorry. As with showModalDialog() we would really like to make this
>  feature disappear. I realize this makes some forms of code generation
>  harder, but hopefully you can find a way around that in time.


Perhaps we should set some sense of expectation about*when*  it won't work. 
Different parts of the Web move on different timelines.


Right.

Also (I am a WHATWG cofounder) it is overreach to promise obsolescence 
on any timeline on the Web. Robert should not worry about real browser 
implementors breaking content by removing sync XHR -- to do so would be 
to lose market share.


In this light, WHATWG should avoid making indefinite-timescale, 
over-ambitious assertions. The W3C was rightly faulted when we founded 
the WHATWG for doing so.


/be

Re: Blocking message passing for Workers

[Brendan Eich]

David Bruant wrote:
I proposed exposing both here 
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0164.html
Jonas Sicking wasn't sold 
http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0165.html


You didn't reply, but we now have a good argument thanks to your point 
here, about reusing async-only JS libraries.



And I haven't found later replies on this topic.


Alon replied to Jonas, saying somewhat more gently what I said about 
generators/async-functions/whole-program-CPS-conversion being infeasible 
for Emscripten:


http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0175.html

Jonas's desire for parsimony is a good design bias, but we now have a 
reason to consider async as well as sync APIs for workers.


However, I'd still want some case analysis. Do we see Emscripten using 
IndexedDB to emulate a synchronous filesystem? If we have a sync f/s API 
that's closer to Unix/C, perhaps there's no Emscripten-based need. 
Cc'ing Alon, assuming Jonas will catch up on the list.


/be

Re: Blocking message passing for Workers

[Brendan Eich]

David Bruant wrote:
That's not what I had understood. So both types of APIs (sync and 
async) will be available to workers for say, IndexedDB?
If that's the case, I have no problem with it and we can stop the 
discussion.
What I remembered of the state of the consensus was that given sync 
APIs were considered needed in workers, they would be added to workers 
without the async counterpart (since that would duplicate the API 
surface).


Sorry I missed this -- do you have a link to the thread?

If I understand you, you're arguing for everyone manually inverting 
control flow, because that maximizes code re-use.
That's what everyone is already used to doing already (not because of 
code reuse, but because that's how JS APIs are designed).


This is a circular argument. We have a choice for workers to do 
something different (and in addition, not instead-of).


/be

Re: Blocking message passing for Workers

[Brendan Eich]

David Bruant wrote:

Le 12/08/2014 02:11, Brendan Eich a écrit :

David Bruant wrote:

Le 09/08/2014 16:22, Brian Kardell a écrit :


On Aug 9, 2014 10:16 AM, "David Bruant" <mailto:bruan...@gmail.com>> wrote:
> There is still a case for blocking primitives for projects that 
compile from other languages (C, C++, Python, Java, C#, etc.) to JS 
[3].

>

I'm glad to be switching last night's twitter discussion to a 
bigger medium.  My question here is: what is the proposal (if there 
is any) to balance these and simultaneously ensure that we don't 
wind up limiting ourselves or providing really bad foot guns or two 
APIs depending on whether you're in the main thread or a worker?


There isn't such proposal and I don't think that can exist which is 
one reason I'm opposed to the introduction of blocking primitives in 
workers.


I really hope the compile-to-JS use cases will find another way to 
be solved.


There is no other way.

Why are you arguing from dogma instead of reason?
It won't be possible to run the same code (libraries) in workers and 
main thread. That's a reason, not a dogma.


It's not much of a reason :-P.

Workers don't have all the APIs that main-thread JS has today. What's 
more, if one chooses to write async-only code for all contexts, then 
there's no problem. Only code written to use a synchronous API would be 
hard to port to the main thread.


If I understand you, you're arguing for everyone manually inverting 
control flow, because that maximizes code re-use. Why not let authors 
maximize or not? Trade-offs exist along multiple dimensions here, and 
code reuse is only one good to consider.


Anyway, the Emscripten (and many other compilers) use-case remains. It's 
not something to hand-wave away.


People already don't use workers that much (because of copy cost 
outweighing computing in most use cases and too many people are still 
unaware of transferables).


This has nothing to do with the subject.

I mean, sure: there are probably lots of reasons workers are underused 
(see above about missing main-thread APIs), but I doubt that among those 
reasons is the fear of blocking i/o primitives being exposed to workers 
and thereby limiting migration of blocking-worker code -- which would 
have to be written only for that content -- onto the main thread!


Once we have blocking i/o in workers, you may find workers used more in 
practice, certainly by Emscripten'ed code.


With C, Java and all, we already know where adding blocking I/O 
primitives leads to. Admittedly maybe dogma trying to learn from history.


You're appealing to something here, but I can't tell what. "C, Java and 
all" have not all failed as languages or successful server-side systems 
because of blocking i/o primitives. More the reverse.


Is this Node.js triumphalism? Be careful: notable Node hackers have left 
for Go. Node is not a proof that non-blocking is always and only ever 
the one true way or the best way to do i/o and utilize CPUs, by any means.


/be

Re: Blocking message passing for Workers

[Brendan Eich]

David Bruant wrote:

Le 09/08/2014 16:22, Brian Kardell a écrit :


On Aug 9, 2014 10:16 AM, "David Bruant" > wrote:
> There is still a case for blocking primitives for projects that 
compile from other languages (C, C++, Python, Java, C#, etc.) to JS [3].

>

I'm glad to be switching last night's twitter discussion to a bigger 
medium.  My question here is: what is the proposal (if there is any) 
to balance these and simultaneously ensure that we don't wind up 
limiting ourselves or providing really bad foot guns or two APIs 
depending on whether you're in the main thread or a worker?


There isn't such proposal and I don't think that can exist which is 
one reason I'm opposed to the introduction of blocking primitives in 
workers.


I really hope the compile-to-JS use cases will find another way to be 
solved.


There is no other way.

Why are you arguing from dogma instead of reason? There's no *reason* to 
say worker overhead is so expensive we should not allow authors to 
create more workers as needed when some block (temporarily, let's hope 
on non-main-thread sync input operations?


/be

Re: Fallout of non-encapsulated shadow trees

[Brendan Eich]

Boris Zbarsky wrote:

On 7/1/14, 9:13 PM, Brendan Eich wrote:

Are you sure? Because Gecko has used XBL (1) to implement, e.g., , or so my aging memory says.


We use XBL to implement .


Also  playback controls, per your next message.

We do not use XBL to implement , though there was 
once a project to do that sort of thing.


Thanks.

There's a lot of prior art here to inform this discussion and (I hope it 
already did inform) shadow DOM. But it seems like not everyone knows or 
remembers the full story, definitely including me.


To get to the promised land, we need to share the same bible. Who is the 
Shadow DOM / WebComponents Moses?


/be

Re: Fallout of non-encapsulated shadow trees

[Brendan Eich]

Domenic Denicola wrote:

From: Brendan Eich [mailto:bren...@secure.meer.net]


>  I don't even know what 3 means. Is it well defined, or just some utopia?


I think it is as well defined as 2 is. Both are really in terms of vague 
requirements:

2. Widget libraries should be implementable without leaking implementation 
details to non-determined consumers.


This is what  relies on in Gecko, IINM, so there's an 
existence proof and practical (if single-implementation) definition.


You did not reply to my point that we have (2) and it's not 
"unexplained", nor does a spec for it "explain nothing". It may be 
overspecified by the one implementation in Gecko, but it's along the 
lines of what Maciej and Ted presented.



3. Widget libraries should be implementable without leaking implementation 
details to determined consumers.


Sounds like some evolution of Shadow DOM to use Google Caja => SES, etc. 
Where SES is not a utopia, but not widely used either; considered 
burdensome (fairly or not).



>  Let's work on 1 first, then get to 2, and declare victory.


I think the crux of my argument is that this would be a mistake.


What "this"? You want to stand on (1) till (3) is figured out and made 
practical? You have to account for (2) sufficing in Firefox still, and 
justify making perfect enemy of good (always a mistake in my book).



>  If Maciej is loath to implement 1 before 2, because widget APIs will leak 
implementation details, perhaps we shouldn't standardize in a hurry. I still see 
value in multiple implementors tracking a draft standard spec.


I fully agree with this, however.


Pronoun trouble again. If by "this" you mean "multiple implementors 
tracking a draft standard spec", then we shouldn't have any vendor 
arguing "shipped it, set the standard, spec is frozen". Right?


/be

Re: Fallout of non-encapsulated shadow trees

[Brendan Eich]

Domenic Denicola wrote:

From: Brendan Eich [mailto:bren...@secure.meer.net]

>  That is a false idol if it means no intermediate steps that explain some but 
not all of the platform.


Sure. But I don't think the proposed type 2 encapsulation explains any of the 
platform at all.


Are you sure? Because Gecko has used XBL (1) to implement, e.g., type=file>, or so my aging memory says. That's "good enough" and it has 
shipped for years, unless I'm mistaken.



>  Sorry, I'm confused. What do we have now, already, among top browsers that is 
"good"? Or do you mean prospective stuff? Because among interoperating browsers, 
AFAIK we do not have any XBL2 or Shadow DOM or other such, after all these years.


I am not sure of your definition of prospective and top browsers, but according 
tohttps://jonrimmer.github.io/are-we-componentized-yet/  and linked issues, Chrome/Opera 
is shipping and Firefox is shipping behind a flag. And by shipping, I mean shipping the 
current shadow DOM spec, which I consider "good."

(Although,https://bugzilla.mozilla.org/showdependencytree.cgi?id=811542&hide_resolved=1
  shows that Firefox has lots of outstanding bugs, so I can't really say how close 
they are to unflagging.)


I meant "all" by "top browsers". Otherwise "we" (developers) don't 
really "have now" any cross-browser web component to stand on and resist 
2nd or 3rd variations.



>  Could you enumerate the three versions (in any sense) of web components in 
the worst case you cite above?


Sure. They would be:

1. What is being shipped now/the current shadow DOM spec


You're getting ahead of your own terms of debate here. Any "we" who 
"have" WC in this list, or another standards body list, must be 
developers dealing with all top browsers, at least.



2. A version of it that gives soft encapsulation
3. A version of it that gives true encapsulation, suitable for implementing 
built-ins


See above about . Boris should weigh in.

I don't even know what 3 means. Is it well defined, or just some utopia? 
I didn't see anyone seriously propose it.



The relative badness of having 1+2+3 vs. just 1+3 is largely a function of what 
"version" ends up meaning. If it is a small additional flag, no big deal. If it 
is three separate conceptual models and APIs, bad news.


You do seem to be making some perfect over good choices, but perfect is 
no-place -- it doesn't exist.


Let's work on 1 first, then get to 2, and declare victory. If Maciej is 
loath to implement 1 before 2, because widget APIs will leak 
implementation details, perhaps we shouldn't standardize in a hurry. I 
still see value in multiple implementors tracking a draft standard spec.


/be

Re: Fallout of non-encapsulated shadow trees

[Brendan Eich]

Domenic Denicola wrote:

Well, but*for explaining the platform*  it is just as useless.


That is a false idol if it means no intermediate steps that explain some 
but not all of the platform.



  It may be useful independently for authors who wish to protect against 
interference by people who are afraid of feeling bad, but it is not useful for 
explaining the platform.

My personal perspective is that it is already a shame we are on track to have two versions (in some sense) of 
web components: the existing one, and one that explains the platform. It would be a shame to have a third in 
between those two, that is unlike the existing one but also does not explain the platform. So I guess along 
this axis I would strongly prefer "perfect" to "good," I suppose because I think what we 
have already is "good."


Sorry, I'm confused. What do we have now, already, among top browsers 
that is "good"? Or do you mean prospective stuff? Because among 
interoperating browsers, AFAIK we do not have any XBL2 or Shadow DOM or 
other such, after all these years.


Could you enumerate the three versions (in any sense) of web components 
in the worst case you cite above?


/be

Re: Fallout of non-encapsulated shadow trees

[Brendan Eich]

I meant Shadow DOM below, where I wrote Web Components.

IIRC Mozilla second, Google first, are implementing. Anyone else?

/be

Brendan Eich wrote:
I'm not saying WebComponents aren't good enough, note well. Sounds 
like they're pretty good and can be evolved and built upon to be even 
better in later iterations. If they can't be minimized much for the 
first interoperable spec, then full speed ahead -- but beware 
premature standardization. Need more implementations coming up in 
parallel. Who is implementing for real right now? 

Re: Fallout of non-encapsulated shadow trees

[Brendan Eich]

Domenic Denicola wrote:

True encapsulation, wherein each element gets some kind of isolated world in 
which to implement itself, is much harder. Blink-in-JS [1] accomplishes 
something along these lines, but does not leverage custom elements, shadow DOM, 
or the like, and essentially works by redirecting through a WebIDL binding 
layer. Perhaps we can draw inspiration from there.

[1]:https://docs.google.com/a/google.com/presentation/d/1XvZdAF29Fgn19GCjDhHhlsECJAfOR49tpUFWrbtQAwU/edit


Mozilla did XUL and XBL what, 15 years ago? JS implementing IDL (XPIDL, 
whatever) interfaces, interoperating with C++, XBL bindings to compose 
elements out of other elements. It's doable, especially if you avoid the 
temptation to seek perfectection ("true encapsulation"). Enemy of the 
good, and all that.


I'm not saying WebComponents aren't good enough, note well. Sounds like 
they're pretty good and can be evolved and built upon to be even better 
in later iterations. If they can't be minimized much for the first 
interoperable spec, then full speed ahead -- but beware premature 
standardization. Need more implementations coming up in parallel. Who is 
implementing for real right now?


/be

Re: WebApp installation via the browser

[Brendan Eich]

Jeffrey Walton wrote:

On Fri, May 30, 2014 at 9:04 PM, Brendan Eich  wrote:

Jeffrey Walton wrote:

Are there any platforms providing the feature? Has the feature gained
any traction among the platform vendors?

Firefox OS wants this.

Thanks Brendan.

As a second related question, is an Installable WebApp considered a
side-loaded app?


Sicking can answer with more authority, but side-loaded or downloaded, 
so long as the user installs it, no difference.


/be

Re: WebApp installation via the browser

[Brendan Eich]

Jeffrey Walton wrote:

Are there any platforms providing the feature? Has the feature gained
any traction among the platform vendors?


Firefox OS wants this.

/be

Re: [Gamepad] Liveness of Gamepad objects

[Brendan Eich]

Boris Zbarsky wrote:
For what it's worth, the way Gecko implements this is by setting up 
that lifetime guarantee only when an expando is added to the object 
(or some other things, like use as a WeakMap key, happen).  Until then 
we allow it to be GCed.


What do other engines do in general? Unobservable GC is a requirement, 
if you ask me and Mark Miller.


/be

Re: [fullscreen] Problems with mouse-edge scrolling and games

[Brendan Eich]

Glenn Maynard wrote:
It's not the application's job to keep the mouse cursor responsive, 
it's the system's.  Hiding the system mouse cursor and drawing one 
manually is always a bad idea.


Agreed!

In the same vein, programmers cannot avoid GC pauses without relying on 
pause-free or at least incremental GC (which BTW some browsers' JS 
engines have already, e.g., SpiderMonkey in Firefox), or as a real 
alternative, cross-compiling C or C++ for example via Emscripten, to 
allocate heap memory from a typed array.


Florian, your goals are good, but the means to those ends must involve 
better runtimes or compilers -- not on JS programmers working harder to 
avoid GC while still somehow allocating objects frequently and even 
implicitly.


/be

Re: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

[Brendan Eich]

Ryosuke Niwa wrote:
As for the social "endorse" button, I've never seen a popular SNS 
share buttons implemented using HTML button elements; most of them add 
their own DOM to add icons, etc...


Right you are. And there's a deeper reason why "like" ("endorse", LOL) 
buttons use iframes: the ability to set 3rd party cookies.


/be

Re: [webcomponents] Auto-creating shadow DOM for custom elements

[Brendan Eich]

What does polymer do? Cows are already treading paths.

I still smell a chance to do better out of the gate (gave, thanks 
autospellcheck! lol). Call me picky. Knee-jerking about scenario solving 
(I think I taught Yehuda that one) doesn't help. Particular response, 
please.


/be

Re: [webcomponents] Auto-creating shadow DOM for custom elements

[Brendan Eich]

(I'm an extensiblewebmanifesto.org signer.)

Separate specs that compose well are great, and all.

Requiring this kind of boilerplate out of the gave is not:

this.createShadowRoot().appendChild(document.importNode(template.contents));

Wanting to avoid this kind of boilerplate is not a "stab in the dark". 
Why can't we avoid it, even with separate specs that compose well? Part 
of composing well is not requiring excessive boilerplate.


/be

Re: Polished FileSystem API proposal

[Brendan Eich]

Hard links are peculiar to Unix filesystems. Not interoperable across 
all OSes. Symbolic links, OTOH...


/be


Brian Stell 
October 29, 2013 4:53 PM
I meant

   eg, V1/dir1/file1, V2/dir1/file1.

Re: Allow javascript: URIs for registerProtocolHandler

[Brendan Eich]

Anne van Kesteren 
September 17, 2013 12:25 PM

Really? I thought registerProtocolHandler() was only a hook for
navigation. As an aside, the plan of record is to limit javascript
URLs to navigation.


Unless they result in undefined, in which case they evaluate against the 
current DOM. This is crucial for bookmarklets, right? (Not allowed when 
typed or pasted into the navigation toolbar).


/be

Re: [DOM4] Short and Efficent DOM Traversal

[Brendan Eich]

Domenic Denicola wrote:

`.iterator()` is a nonstandard Mozilla-ism;


Rather, a temporary state while we were arguing about ES6 and waiting 
for symbols to be specified (still waiting). It's not a permanent addition.


/be

Re: CSP 1.1 DOM design

[Brendan Eich]

David Bruant wrote:
This M.O. is exacerbated by the reality that most of the folks 
writing these specs are C++ hackers, not JS developers. For many, 
WebIDL becomes a safety blanket that keeps them from having to ever 
think about the operational JS semantics or be confronted with the 
mismatches.

Interesting. I wasn't aware of that.
Any idea as to how to improve the state of things? It seems to be much 
more a human problem than a WebIDL problem. Even if WebIDL improves, 
people will likely still do the copy/paste dance, no?


What Alex describes is inherent in having any IDL language between 
native implementations and JS clients. Going through the exercise Alex 
advocated earlier for testing API completeness, of implementing using JS 
instead of C++, is one way to try to overcome this problem. Boris and 
probably others have experience here, since Proxies in ES6 allow 
implementation where JS without Proxies was insufficient.


We could get rid of WebIDL and specify interfaces only in JS, but 
without enough declarative forms that is too abstraction-leak-prone and 
high-overhead. Beating on WebIDL with the JS stick seems like the way to go.


/be

P.S.: Kudos to Alex, Arv, et al. for fighting the good fight!

Re: Moving File API: Directories and System API to Note track?

[Brendan Eich]

Glenn Maynard wrote:
I'm interested in the same from Mozilla side: what are the real issues 
that you think are unsolvable, or do you just think the underlying use 
cases aren't compelling enough for the work required?


Speaking for myself, not for all Mozillans here, I find the use-cases 
Eric U listed two messages ahead of yours in the thread compelling. I 
like the interface Maciej synthesized from prior designs. Filesystems 
are not databases and they have their uses. This is not a difficult 
proposition! Of course, when all you have is a database then everything 
looks like your thumb... :-|


/be

Re: IndexedDB: undefined parameters

[Brendan Eich]

Boris Zbarsky wrote:
Should "undefined", when provided for a dictionary entry, also be 
treated as "not present"?  That is, should passing a dictionary like so:


  { a: undefined }

be equivalent to passing a dictionary that does not contain "a" at all?


ES6 says no. That's a bridge too far. Parameter lists are not objects!

/be

Re: IndexedDB: undefined parameters

[Brendan Eich]

Boris Zbarsky wrote:
In fact, WebIDL doesn't even do what you want here with 
[TreatUndefinedAs=Missing].  All that does is that if it's present on 
an argument and all arguments after it, and if all the values passed 
for all those arguments are undefined, then the effective overload 
used is the one with all those arguments omitted.  So if you have this 
IDL:


  void foo([TreatUndefinedAs=Missing] optional int foo,
   [TreatUndefinedAs=Missing] optional int bar);

and you make this call:

  foo(undefined, 5)

this will behave the same as foo(0, 5).

Basically, TreatUndefinedAs=Missing is meant to let you pretend like 
trailing undefined values don't affect arguments.length, in ES terms.


This is all consistent with draft ES6, per Ecma TC39 and its Editor, @awbjs.

http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts

undefined is the one value that acts as the default-triggering sentinel, 
whether trailing or not. This supports composition by delegation, where 
f(a,b,c) and f calls g(a,b,c) and g has default parameters triggers 
defaulting no matter how many or few actual arguments f receives -- 
without f having to specialize on arguments.length and call g with 0, 1, 
or 2 actuals.


Think about all this from the point of view of an ES impl of foo() 
above.  How would you represent, in an ES function that expects its 
first argument to be an int and the second argument to be an int but 
makes them optional, the concept of "second int passed, but first not 
passed"?  However you'd do that, that's probably what WebIDL should 
aim for.


undefined as first actual, int as second.

ccing public-script-coord here, because it seems like there's some 
serious lack of clarity about what WebIDL does now and what behavior 
people want out of it.


ES6 draft on default parameters is now clear.

/be

Re: Moving File API: Directories and System API to Note track?

[Brendan Eich]

Maciej Stachowiak wrote:

On Sep 22, 2012, at 9:35 PM, Maciej Stachowiak  wrote:


On Sep 22, 2012, at 8:18 PM, Brendan Eich  wrote:


And two of the interfaces are generic and reusable in other contexts.

Nice, and DOMRequest predates yours -- should it be done separately since (I 
believe) it is being used by other proposals unrelated to FileSystem-like ones?

Sorry if I missed it and it's already being split out.

Yes, I borrowed DOMRequest. I think DOMRequest and DOMMultiRequest could be a 
separate spec, if that sort of asynchronous response pattern is generally 
useful. And it seems like it might be. That would leave only two interfaces 
specific to the Minimal File System proposal, Directory and FileHandle.


Here's an alternate version where I renamed some things to match Filesystem API 
and FileWriter, and added the missing key feature of getting a persistent URL 
for a file in a local filesystem (extending the URL interface). It's still a 
much simpler API that provides most of the same functionality.

https://trac.webkit.org/wiki/MinimalFileStorageAlternate


Even better.

What's the next step? I would hope we can make device storage be this, 
but that's just old Unix-hacker me (yes, no pathnames, you have to namei 
by calling get for each component -- that's a feature).


/be

Re: Moving File API: Directories and System API to Note track?

[Brendan Eich]

Maciej Stachowiak wrote:

On Sep 21, 2012, at 10:10 PM, Jonas Sicking  wrote:


For what it's worth, I put together a draft for what an API would look
like that has basically the same feature set as the current FileSystem
API, but based on DeviceStorage. It's a much smaller API that the
current FileSystem drafts, but supports things like shallow as well as
deep directory iteration.

https://wiki.mozilla.org/WebAPI/DeviceStorageAPI2

I think that if we at mozilla were to implement a sandboxed
filesystem, it'd be something more like this.


I took a crack at a pruned and cleaned up version:

https://trac.webkit.org/wiki/MinimalFileStorage

Only 4 interfaces (excluding the Navigator addition), 16 methods, 9 attributes. 



Nice!


And two of the interfaces are generic and reusable in other contexts.


Nice, and DOMRequest predates yours -- should it be done separately 
since (I believe) it is being used by other proposals unrelated to 
FileSystem-like ones?


Sorry if I missed it and it's already being split out.


It removes cruft but adds features relative to the Mozilla version:

- Atomic create/open operation


As an old Unix hacker, this warms my heart. (I ignore the camelCaps 
method multiplication to avoid O_ flags, and the spelled-out creatE ;-)



- Renaming files and directories


Atomic rename, must have.


- A Directory interface for less weirdness in directory handling


+1

- Ability to open files in append mode (this makes more sense than an append() operation on the handle, given the way underlying filesystems work) 



Yup.


Features omitted include:
  - Multiple named filesystems (just use directories)


Exactly. Do we still call them mount points?


- Separate enumeration for writing (just use open)


Yup.

- Ability to fetch matadata (does not appear to be needed for the use case) 



Whatsa mata with matadata? :-P

Ok, defer. Fine by me unless Sicking has a pressing use-case to articulate.

It could be simplified a little bit, but really not that much, by removing hierarchy. 



Hierarchy is much of the point here.

I like the way this is going.

I'm curious how things look in hindsight to Google folks. Was the whole 
of FileSystem truly needed? Even if "whole" properly excludes the 
synchronous APIs?


/be

Re: Sync API for workers

[Brendan Eich]

David Bruant wrote:

I can imagine, it sounds hard indeed. Do you have numbers on how it
affects performance? Or an intuition on these numbers? I don't need to
be convinced that it affects performance significantly, but just to get
an idea.


This is not going to be easy to estimate, but you might benchmark 
generator vs. non-generator code in the latest SpiderMonkey.


I don't think we need quantification, though. Alon's right, the 
optimizing VMs are not focused on uncommon code other than what's in the 
dopey industry-standard benchmarks.



I remember that at some point (your JSConf.eu talk last October), in
order to be able to compile through Emscripten, the source codebase (in
C/C++) had to be manually tweaked sometimes. Is it still the case? If
it's an acceptable thing to ask to authors, then would there be easy
ways for authors to make their IO blocking code more easily translated
to async JS code? I'm pessimistic, but it seems like an interesting
question to explore.


BananaBread required zero Cube 2 changes, IIRC. Other Emscripten 
examples are also pure compilation.


Forget it. Inversion of control flow is hard enough and error prone that 
developers won't do it. It's the #1 reason Mozilla's Electrolysis 
project is paused indefinitely. The SuperSnappy work (threads, not 
processes) preserves most execution model compatibility, and avoids 
requiring programmers writing Firefox XUL front-end and add-on code from 
having to manually callback-CPS their code (on every DOM access!).


/be

Re: [IndexedDB] Problems unprefixing IndexedDB

[Brendan Eich]

From: Kyle Huey 
>
> Jonas mentioned earlier on this list that we unprefixed IndexedDB in
> Firefox nightlies some time ago.  We ran into a bit of a problem.[0]  
Most

> of the IndexedDB tutorials (including ours and HTML5 Rocks[1] :-/) tell
> authors to deal with prefixing with:
>
> var indexedDB = window.indexedDB || window.webkitIndexedDB ||
> window.mozIndexedDB || window.msIndexedDB || ...
>
> This code has a bug when executed at global scope.  Because the 
properties
> are on the prototype chain of the global object, 'var indexedDB' 
creates a

> new property on the global.

Not according to ECMA-262 Edition 5.1 or conforming implementations of it.

Firefox's JS engine, SpiderMonkey, actually helped get ES5.1 to match JS 
reality and past editions, where ES5 tried to spec what you describe in 
the last paragraph cited above. We found that incompatible, rolled it 
back in


https://bugzilla.mozilla.org/show_bug.cgi?id=632003

and filed an erratum on ES5 which was fixed for ES5.1 (the ISO version 
of ES5).


Unfortunately this bug regressed SpiderMonkey to ES5 status quo ante:

https://bugzilla.mozilla.org/show_bug.cgi?id=722121

I only just noticed, due to the unprefix-indexedDB issue you raise. I filed

https://bugzilla.mozilla.org/show_bug.cgi?id=781739

to get SpiderMonkey fixed.

The takeaway is to never assume a recently modified JS engine matches 
the latest ECMA spec. Sad to report this one involved SpiderMonkey, but 
it hits all evolving engines, and the spec can have bugs too (as 
described above in ES5). The ES5.1 spec is quite clear that the 
prototype chain is checked and no such property found, before a 'var' 
declaration makes a fresh binding with default value undefined.


So no need for WebIDL, IndexedDB, or ES5.1 to change.

/be

Re: [XHR] Constructor behavior seems to be underdefined

[Brendan Eich]

See the [[Scope]] internal property of function objects from ECMA-262 
13.2, 10.4.3, etc.


/be

Boris Zbarsky wrote:
As far as I can tell, the WebIDL specification doesn't define anything 
about what really happens when a constructor is invoked, once the 
arguments have been converted to the IDL types, except the conversion 
of the return value from an IDL type to an ES type.  It defers the 
exact behavior of the constructor to the specification defining the 
constructor.


XHR2 currently says in 
http://www.w3.org/TR/XMLHttpRequest2/#constructors :


  The XMLHttpRequest() constructor must return a new XMLHttpRequest
  object.

and in http://www.w3.org/TR/XMLHttpRequest2/#origin-and-base-url :

  In environments where the global object is represented by the Window
  object the XMLHttpRequest object has an associated XMLHttpRequest
  document which is the document associated with the Window object for
  which the XMLHttpRequest interface object was created.

Now consider a web page with two subframes and a script that has 
references to the two subframe windows in variables w1 and w2.  Then 
the script does this:


  w1.XMLHttpRequest = w2.XMLHttpRequest;
  var xhr = new w1.XMLHttpRequest();

What's the document associated with xhr?  Is it w1.document, 
w2.document, or window.document?  The concept "the Window object for 
which the XMLHttpRequest interface object was created" doesn't seem to 
be defined anywhere


-Boris

Re: What type should .findAll return

[Brendan Eich]

On Nov 14, 2011, at 3:32 PM, Yehuda Katz wrote:

> Sorry,
> 
> I was making a joke (referencing 1.5.2 of the HTML5 spec), not intending to 
> be confrontational.

Ah, I get it -- indeed such deviations were one of the reasons for creating 
public-script-coord.

SO I get it but I didn't lul. :-|


> The underlying issue here is just making it possible for Array.isArray to 
> return true for an Array of DOM nodes that is also enhanced with extra 
> features. Jonas had specifically said that he wanted isArray to work. Rick 
> then pointed out that the spec seems to disallow host objects from claiming 
> that their [[Class]] is Array, and that isArray specifically requires that 
> [[Class]] be Array.

We need to get this right in the future. It's a tricky issue. But even now I 
would say that if there's no observable difference, there is no problem. Allen 
should weigh in.

/be


> 
> I apologize again for my in-jest comment.
> 
> Yehuda Katz
> (ph) 718.877.1325
> 
> 
> On Mon, Nov 14, 2011 at 3:23 PM, Brendan Eich  wrote:
> On Nov 14, 2011, at 3:13 PM, Yehuda Katz wrote:
> 
>> It seems as though the spec intends to disallow host objects (i.e. DOM) from 
>> fully acting like an Array, which is clearly the intent here. Perhaps this 
>> is a time for "willful disobedience" and a correction in ES6?
> 
> Calm down -- this confrontational style is unjustified.
> 
> The spec cannot deal in non-observables. DOM host objects in most 
> implementations are full of methods, which really are native function 
> objects. But it's always possible to implement a work-alike. So long as a 
> host array follows the contract in every observable way, no problem.
> 
> What's at issue is the abuse of internal methods defined only for 
> spec-internal purposes as arbitrary "plugin APIs" by other specs. That's 
> where negotiation and future-proofing are needed.
> 
> /be
> 
>> 
>> Yehuda Katz
>> (ph) 718.877.1325
>> 
>> 
>> On Mon, Nov 14, 2011 at 10:46 AM, Rick Waldron  
>> wrote:
>> [snip]
>>  
>> ES5.1 clause 8.6.2 says: 
>> >   "The value of the [[Class]] internal property of a host object 
>> > may be any String value except one of "Arguments", "Array",..."
>> > In other words, host object provides (such as a DOM implementation) are 
>> > not allowed to define new kinds of objects whose [[Class]] is Array.
>> > It's fine to want to define a new kind of host object that is behaviorally 
>> > very similar (but slight different) from instances of the built-in Array 
>> > constructor.  But characterizing such objects by saying they have 
>> > [[Class]]=="Array"
>> >  is a not meaningful from a ES5.1 specification perspective.
>> 
>> I'm fine with any formulation, as long as it gives the correct behaviour in 
>> cases like Array.prototype.concat and Array.isArray.
>> 
>> ES 5.1 15.4.3.2 Array.isArray()  
>> ...
>> 2. If the value of the [[Class]] internal property of arg is "Array", then 
>> return true.
>> ...
>> 
>> Considering Allen's previous comment, this is not going to be allowed.
>> 
>> Rick
>>  
>> 
>> Do you have suggestions for what to write?
>> 
>> / Jonas
>> 
>> 
> 
> 

Re: What type should .findAll return

[Brendan Eich]

On Nov 14, 2011, at 3:13 PM, Yehuda Katz wrote:

> It seems as though the spec intends to disallow host objects (i.e. DOM) from 
> fully acting like an Array, which is clearly the intent here. Perhaps this is 
> a time for "willful disobedience" and a correction in ES6?

Calm down -- this confrontational style is unjustified.

The spec cannot deal in non-observables. DOM host objects in most 
implementations are full of methods, which really are native function objects. 
But it's always possible to implement a work-alike. So long as a host array 
follows the contract in every observable way, no problem.

What's at issue is the abuse of internal methods defined only for spec-internal 
purposes as arbitrary "plugin APIs" by other specs. That's where negotiation 
and future-proofing are needed.

/be

> 
> Yehuda Katz
> (ph) 718.877.1325
> 
> 
> On Mon, Nov 14, 2011 at 10:46 AM, Rick Waldron  wrote:
> [snip]
>  
> ES5.1 clause 8.6.2 says: 
> >   "The value of the [[Class]] internal property of a host object 
> > may be any String value except one of "Arguments", "Array",..."
> > In other words, host object provides (such as a DOM implementation) are not 
> > allowed to define new kinds of objects whose [[Class]] is Array.
> > It's fine to want to define a new kind of host object that is behaviorally 
> > very similar (but slight different) from instances of the built-in Array 
> > constructor.  But characterizing such objects by saying they have 
> > [[Class]]=="Array"
> >  is a not meaningful from a ES5.1 specification perspective.
> 
> I'm fine with any formulation, as long as it gives the correct behaviour in 
> cases like Array.prototype.concat and Array.isArray.
> 
> ES 5.1 15.4.3.2 Array.isArray()  
> ...
> 2. If the value of the [[Class]] internal property of arg is "Array", then 
> return true.
> ...
> 
> Considering Allen's previous comment, this is not going to be allowed.
> 
> Rick
>  
> 
> Do you have suggestions for what to write?
> 
> / Jonas
> 
> 

Re: What type should .findAll return

[Brendan Eich]

On Nov 11, 2011, at 3:07 PM, Allen Wirfs-Brock wrote:

>> I'm happy to start a separate thread on es-discuss about this, but I'm
>> worried that it'll fragment the current thread.
> 
> In theory, public-script-coord exists for exactly this sort of discussion and 
> the ESdiscuss people who care should be subscripted. Rather than starting a 
> new thread, perhaps should should just post to es-discuss a pointer to this 
> thread.
> 

Turns out (thanks Jake!) we do have an es-discuss thread of interest:

https://mail.mozilla.org/pipermail/es-discuss/2011-November/018242.html

/be

Re: What type should .findAll return

[Brendan Eich]

On Nov 11, 2011, at 10:44 AM, Jonas Sicking wrote:

> On Fri, Nov 11, 2011 at 10:06 AM, Brendan Eich  wrote:
>> On Nov 11, 2011, at 1:05 AM, Jonas Sicking wrote:
>> 
>>> And to ensure that the object acts as much as possible as an array it
>>> should also have it's [[Class]] set to that of an array.
>> 
>> This is not something to do lightly -- at least cross-post the first message 
>> to es-disc...@mozilla.org and set reply-to followups-to. Cc'ing Allen.
>> 
>> Note that [[Class]] is going away in ES.next.
>> 
>> The internal methods and properties of ECMA-262 are not arbitrary extension 
>> points for other specs to use without consultation.
> 
> Yup, that's why i cc'ed public-script-coord.

That's why I'm asking you to cc: es-discuss. I expect Allen will catch up with 
this thread, but you may get more prompt responses from various people by using 
es-discuss for the initial message.


> Note that what I'm suggesting in this thread is to create a real
> normal Array. "Just" one with an extra object inserted in it's
> prototype chain.

That's not a "real normal Array" then. Boris mentioned one issue 
(optimization). Let's call it an extended array. ES.next should support 
user-extended arrays via the <| operator, so this isn't something "bad", but 
it's not exactly an array.


> So if [[Class]] is going away in ES.next that shouldn't be a problem.
> Whatever will happen to Arrays when that happens, should happen to
> NodeArrays.

Allen analyzed how [[Class]] is used in ES1-5, and broke down the cases. Some 
of these change to a different or more generic way of discriminating on 
"class". Others still need an internal property. Notable among the latter is 
the string name disclosed by Object.prototype.toString.call(anArray).

The deeper issue for arrays is the custom [[DefineOwnProperty]] (ES5) or 
[[Put]] (ES1-3) that maintains length to be one greater than greatest index 
provided the index is < 2^31 - 1.


> The separate issue of making .filter and friends work can be solved in
> multiple ways. At least some of which require no changes to
> Array.filter if that is preferable from a language point of view.

This sounds right.

/be

Re: What type should .findAll return

[Brendan Eich]

On Nov 11, 2011, at 1:05 AM, Jonas Sicking wrote:

> Hi All,
> 
> So, we've debated a lot the exact syntax for .find/.findAll. However I
> intentionally requested that we split out the discussions about return
> type for .findAll to a separate thread. So I'm starting that thread
> here.
> 
> There are a few goals for the return'ed object that I've envisioned
> based on discussions so far:
> 
> 1. It should have at least all of the non-mutating Array methods on
> it. Possibly the mutating methods too if we allow the returned object
> to be mutable.
> 2. It should have a object on the prototype chain where we can insert
> functions that are specifically useful for lists of nodes. Examples
> include .find/.findAll/.matchesSelector/.remove/.addEventListener
> 3. It would be good if it had the Array prototype object on it's
> prototype chain so that if Array.prototype was extended, it would
> affect this object too.
> 4. The object will *not* be live since live results from selector
> matching is slow.
> 
> Since the returned object won't be live, I don't see a reason to make
> it immutable. Hence it seems like we could put Array.prototype on the
> prototype chain which would immediately make all non-mutating as well
> as mutating functions available on the object.
> 
> We should also insert a new prototype object in the prototype chain.
> Hence we end up with something like:
> 
> object -> [some type].prototype -> Array.prototype -> Object.prototype.
> 
> And to ensure that the object acts as much as possible as an array it
> should also have it's [[Class]] set to that of an array.

This is not something to do lightly -- at least cross-post the first message to 
es-disc...@mozilla.org and set reply-to followups-to. Cc'ing Allen.

Note that [[Class]] is going away in ES.next.

The internal methods and properties of ECMA-262 are not arbitrary extension 
points for other specs to use without consultation.

/be


> This has
> subtle effects on a number of functions. For example it affects what
> Object.toString() and Array.isArray returns, it affects how
> Array.concat behaves, and it affects the JSON serializer.
> 
> I'm not sure if setting the [[Class]] to that of an array also gives
> the object the magical .length property, but if it doesn't, we need to
> also define that the returned object has such a property. Note that
> for Arrays, .length doesn't live on the prototype chain, but is rather
> a special property on the object itself.
> 
> In other words, the returned object is exactly what you'd get if you did:
> 
> a = new Array;
> a.__proto__ = [some type].prototype;
> [some type].prototype.__proto__ = Array.prototype;
> 
> and then filled a with the set of nodes which matched the selector
> passed to .findAll.
> 
> 
> So the remaining question is, what should we use for [some type]. One
> option is to use NodeList. However this would result in NodeLists
> having Array.prototype on it's prototype chain. Including all mutating
> functions. This is iffy in general since NodeLists are returned from
> several APIs which return objects which represent a live result of a
> query. For example .getElementsByTagName, .getElementsByClassName and
> .childNodes.
> 
> An additional source of iffiness with this idea is that several of the
> mutating methods on Array.prototype don't throw if called on a
> immutable objects. For example .pop, .shift, .sort and .reverse all
> would not throw if called on an empty immutable list.
> 
> Hence I propose that we add a new type. I don't care much for naming
> things so I'll just suggest NodeArray for now and let others fight it
> out over the name.
> 
> For now we can leave NodeArray as empty and just let it be an
> extension point for page authors. We can discuss separately if
> .findAll/.matchesSelector should be added to NodeArray, and if so how
> they should behave.
> 
> However, we should probably use NodeArray to "fix" one of the problems
> with some of the functions on Array.prototype. For example
> Array.prototype.filter always returns a new Array object. This would
> mean that:
> 
> elem.findAll(...).filter(function(node) { ... });
> 
> will return a plain Array and not a NodeArray. However we could make
> NodeArray override all such functions and keep their behavior
> identical except that they return NodeArrays.
> 
> Another way to fix this problem would be to change the definition of
> Array.prototype.filter, but I have no idea if that's doable, or how
> that would be done.
> 
> 
> What do people think?
> 
> / Jonas
> 

Re: [WebIDL] Exceptions

[Brendan Eich]

On Jul 7, 2011, at 10:09 AM, Aryeh Gregor wrote:

> On Wed, Jul 6, 2011 at 9:46 PM, Brendan Eich  wrote:
>> Gecko is buggy if it is using the dynamic scope. Please file that bug and 
>> cc: me.
> 
> Gecko says the exception is an instanceof the DOMException object that
> corresponds to *any* window.  So e instanceof window1.DOMException and
> also e instanceof window2.DOMException.  IIRC, there's already a bug
> filed on this, but I can't find it.

Oh, I dimly recall this now. Earl adaptation to help developers confused by the 
cross-frame instanceof failure case? Not sure how early but I think it's pretty 
old.

If you use Object.getPrototypeOf in a loop (hand-expand instanceof), you can 
probably find out which window's DOMException.prototype is on the chain. That 
would be interesting.

/be

Re: [WebIDL] Exceptions

[Brendan Eich]

On Jul 6, 2011, at 5:05 PM, Jonas Sicking wrote:

> On Wed, Jul 6, 2011 at 2:23 PM, Aryeh Gregor  wrote:
>> On Wed, Jul 6, 2011 at 7:06 AM, Anne van Kesteren  wrote:
>>> So with Web IDL going to Last Call does this mean that the exception model
>>> outlined in http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623#c8 is the
>>> way forward? I.e. we introduce new exception interfaces in DOM Core for all
>>> the different exception types and update all other specifications that use
>>> DOM Core to dispatch those exceptions instead (and they are somewhat
>>> backwards compatible because they inherit from DOMException and therefore
>>> still have the code member).
>>> 
>>> I guess there is no particular rush on this; I am mainly wondering whether
>>> other editors are aware of this change and agree with it.
>> 
>> The thing I don't like about this proposal is that it encourages
>> authors to use "e instanceof IndexSizeError" or similar.  This will
>> work 98% of the time and then fail in an extremely mysterious way when
>> multiple globals are involved.  All you need is the exception to be
>> thrown by something in an iframe for whatever reason.

You have to remember that exceptions came to JS in ES3, the Third Edition of 
ECMA-262, and they followed Java's model but without static nominal types. This 
resulted in the cross-window/frame confusion problem, but ES3 people did not 
take on specifying multiple globals, and they weren't active multi-window/frame 
JS hackers, so they missed this.

(Termination-style exception handling doesn't scale anyway, but that's another 
complaint for another time.)


>> Moreover, I don't even think behavior in that case is defined.  If I
>> call foo.appendChild(bar) and it throws, is the exception from the
>> window where the method was called, or the one foo is associated with,
>> or the one bar is associated with?  Browsers other than Gecko seem to
>> agree it's the one foo is associated with
>> (),
>> and Gecko is just buggy, but is this specced anywhere?  I don't see it
>> in DOM Core.

Gecko is buggy if it is using the dynamic scope. Please file that bug and cc: 
me.


>> I don't see why we need the extra classes.  What's the advantage over
>> just adding the .name attribute, or something equivalent, and not
>> adding new classes?  Just consistency with ES, or something else too?
> 
> This is indeed a good point. The main reason for me was consistency
> with ES. But I'm not sure why ES was designed the way it is. Generally
> it seems like multiple globals wasn't kept in mind a lot when ES was
> designed, though obviously this is a problem for ES on the web.

See above.


> Would love to hear from ES people that surely has spent more time
> thinking about exceptions than me.

There's nothing deep here. You smell something bad in the design that mixes 
instanceof and multiple globals, so I agree the best course is to avoid 
perpetuating it by imitation.

/be

Re: [FileAPI] File.slice spec bug

[Brendan Eich]

On Apr 13, 2011, at 7:01 AM, Darin Fisher wrote:

> Agreed.  I certainly don't assert that whatever Chrome ships first should be 
> regarded as standard.  Our rapid release schedule depends on platform 
> features beginning life with a vendor prefix.  I believe that we goofed in 
> this case by not vendor-prefixing the slice method.  More on this below...

Vendor prefix may just add to the names developers have to juggle, and kick the 
can down the road a bit. If we can go from WD to REC with a single name and 
signature/semantics, even better.

Here is a case where hedging with a vendor prefix arguably would have helped, 
in hindsight. OTOH other HTML5 prototype implementations in the past many years 
did well to avoid vendor prefixes.


> s/Kenneth Arnold/Kenneth Russell/

Jetlag dredged up an old Unix name -- apols to Ken R.


> Blobs are views on immutable data.  WebKit's implementation will reject reads 
> on a Blob, which points to a file that has since been modified.  (This should 
> be part of the spec if it is not.)

This does seem slightly underspecified :-P.


> One option we can consider is to rename Blob.slice to Blob.webkitSlice and 
> adopt the newer arguments.  I think we would want to similarly vendor-prefix 
> BlobBuilder and FileReader as those too are non-standard.  This change runs 
> just as much risk of breaking Chrome-specific content; however, the failure 
> mode (absence of a method) should be easier for apps to cope with.
> 
> I'm not stating that we will do this yet.  I'm just proposing it as another 
> approach to consider.  I'll discuss this idea with others on the team 
> tomorrow.

This sounds like a good way forward for the various parties.


> By the way, I'm not too concerned about having to fix Google web apps.  I'm 
> much more concerned about third-party, Chrome-specific content available as 
> either apps or extensions through the Chrome app store.  It is hard to grep 
> for instances of Blob.slice!!

Indeed. http://codesearch.google.com's regexps are not quite up to this -- need 
to mix in some http://doctorjs.org/ and make a "semantic grep".

/be

Re: [FileAPI] File.slice spec bug

[Brendan Eich]

Dmitry Titov  wrote:
> It can be more then it looks though - if site detects File.slice and then
> uses it, it will automatically pick up FF and Opera now because the method
> now is defined.
FF and Opera just added File slice support, IIUC. For Firefox at least we are 
willing to change things for 4.0.1 or an automatic patch release. Down the 
road, if we change to a better name, this episode will fade away and devs won't 
have to remember it or (more important) learn about it.

But we're late. You're right. I wish I caught this before we shipped Firefox 4. 
It smells like yet another inconsistent or badly named web API _fait accompli_, 
and perhaps it is (a _fait accompli_, I mean; it's badly named in any event).

However: the "Chrome (or any one vendor) shipped it so it can't change" 
virtual-rule put forth with leaning-toward fuzziness is not going to fly in a 
modern, post-duopoly,  multi-vendor browser market.

We need to agree on specs and then prototype them -- and then if some bug is 
found later, be able to change spec and implementations before the spec goes to 
REC. IINM File API is still a WD so in theory we can still do this if we so 
choose.

/be

Re: [FileAPI] File.slice spec bug

[Brendan Eich]

Darin's position is "leaning toward" not breaking compatibility with what 
Chrome has shipped for a while. That's one consideration. It can't be the only 
consideration, or there's no point having a discussion and whatever Chrome 
ships first is an instant standard.

When we talked to Kenneth Arnold of Google about a typed array method that was 
more subtly misnamed "slice", he quickly worked with other WebGL folks to 
rename it to "subarray". That in spite of some support for the typed array 
"slice" method having shipped in some beta releases (at least; not sure if any 
final releases supported slice).

The subtler differences between typed array's subarray (formerly named slice) 
and JS's Array slice:

(a) The subarray method returns a view of mutable ArrayBuffer data, its 
elements alias the elements of the typed array from which it came. This is the 
big reason to avoid using "slice".

(b)  While subarray takes (start, end) parameters and allows end to be omitted; 
and it handles negative indexes; it does not allow start to be omitted too, 
whereas JS (after Python) does.

http://www.khronos.org/registry/typedarray/specs/latest/
http://www.khronos.org/webgl/public-mailing-list/archives/1102/msg00028.html

The DOM is full of crazy inconsistency from insta-standards in the mid-'90s, 
starting with my DOM level 0 work. That is not a good pattern to repeat now 
that we have more balanced market actors and the benefits of hindsight. We 
should try to agree on less inconsistent APIs and prototype them, but no single 
prototype implementation can create a standard. Only interoperable de-facto 
standards can do that.

At this point we need to be completely concrete, no leaning one way or another:

0. Do nothing.

1. Should we change slice, possibly breaking Chrome-only content that detects 
it by name but does not test its functionality?

2. Should we rename slice, allowing Chrome to keep the old name for a while if 
it must?

Solution 0 just leaves a noxious inconsistency on two counts: length not end as 
the second parameter, the lack of negative index support. Is there another 
difference with Array slice (which comes from Python and is in Ruby too)? What 
about optionality of the arguments?

Doing 1 is simpler for future users who don't have to deal with the legacy that 
Chrome-only content might represent.

Doing 2 avoids breaking any such legacy, but may increase the cognitive load 
for users who see the legacy and the new renamed method.

What about negative indexes? Is there time to spec and implement these per 
Python/JS/Ruby?

Without negative index support, the case for 2 is stronger again.

If Blob slice returns an aliasing view onto mutable data instead of a copy, 
just as typed arrays' subarray method does, then the case for 2 is extremely 
strong.

I do not see any mutator methods in http://dev.w3.org/2006/webapi/FileAPI/, but 
with the typed array precedent I didn't want to assume.

I favor 1 if negative index and optional argument semantics can be made to 
match precedent, and assuming no way to mutate shared Blob/sub-Blob data.

If not, I suggest 2, with "subBlob" or a better name -- that one hurts due to 
the shifted-B, but "subblob" seems also bad for the run-together "bb".

/be

Re: [DOMCore] fire and dispatch

[Brendan Eich]

> > 2. Run getters and define in which order they are retrieved
> 
> This can get pretty hard to specify (esp. because it involves describing 
> what happens if those getters reenter the API you're defining).
Why is that particularly hard? Calling fireEvent (or whatever it will be 
called) twice on a given event has to be specified.

This "suppress getters" goal seems like a mistake to me, and ES5 itself does 
not worry about it, even as it both standardizes getters and adds 
objects-as-keyword-parameter-sets to standard library APIs. See

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12248#c2

/be

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

[Brendan Eich]

On Sep 27, 2009, at 4:15 PM, Maciej Stachowiak wrote:


On Sep 27, 2009, at 11:28 AM, Brendan Eich wrote:
But there's no point pretending the Web (ES, DOM, etc.) is an  
example of a well-designed toolkit for building user-facing  
distributed apps!


But we're not really free to discard compatibility. So I'm not that  
excited about the exciting opportunities we could have if we did.  
The Web is a duct tape design but it works. Dropping compatibility  
would kill one of its biggest advantages.


Sure. You didn't see me proposing dropping Web compatibility (suicide  
for browser vendors) -- rather, I'm talking about doing end-to-end  
design as we go, and meeting in the middle.


Too many short hops via a standard body incurs high costs in the spec  
process (some essential, some not) while tending to enshrine mistakes  
over time due to compatibility. Whereas taking big hops risks mission  
creep, or mission cliff-dive into second-system death-beach ;-), or  
even the old mistake of targeting a market foreseen five years out  
that never arrives (the real world zigged instead of zagging).


We've all seen these problems, I think, over our careers. And it's not  
as if the proprietary languages and stacks can break compatibility  
excessively (search for "Visual Fred"). But they can and do provide  
new and more coherent API-sets that help deprecate old ones.


To avoid proprietary stack examples, consider Python's from __future__  
import mechanism:


http://www.python.org/dev/peps/pep-0236/

This precedent is attractive if one can push out new versions of the  
language implementation, with carrots to induce people to upgrade, as  
well as the stick of unsupported ancient versions. It helps that C- 
Python is source-as-spec, but let's say that is a non-issue with good- 
enough ES specs.


The "carrots instead of sticks" idea is more critical from what I have  
seen, for Python and for JavaScript -- we can't get people to stop  
doing what worked if there's no new and better way (the recent  
arguments.callee in strict mode thread highlighted this point).


Of course, the web is too big to try to get away with deprecation/ 
obsolescence cycles on any predictable near-term release schedule.  
Never mind coordination among browser vendors on their next versions  
-- IE6 is still Out There.


But perhaps once past IE6, though, with modern browsers auto-updating,  
we'll see the downrev implementations go away faster. There's a  
chance, anyway, from what I see of IE8 replacing IE7, and of course  
faster updating for other, "fresher" browsers ;-).


If we do see a world where browser version uptake is faster, and the  
downrev problem shrinks or becomes more tractable somehow, then we  
will want shinier duct tape without bits of lint and trash stuck to  
the edges of the tape roll, over time. Every compatibility constraint  
costs non-linearly when refracted through the whole-language design  
process.


So part of ECMAScript "Harmony" is not just "ES6", a prematurely- 
triaged, shortest-path evolutionary jump, but longer-term "end to end"  
design that ultimately puts the TC39 committee out of the language- 
extension business by empowering developers to bootstrap new language  
versions by themselves.



Systems that discard compatibility can also deliver an unusable  
Second System, especially when designed by committee. I would point  
to certain W3C specs that chose to break compatibility with existing  
practice. They are often not only undeployable but also not very  
compelling on their own terms.


Agreed.


I think compatibility constraints, even though they impose messy and  
illogical quirks, can also act as a healthy counterweight to flights  
of design fancy. Constraints make for good art.


We seem to have some unnecessary constraints, which are bad for art  
and science. Let's try to get rid of the foo(i) for foo[i] or  
foo.item[i] non-mandatory compatibility cruft and see how that goes.


/be

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

[Brendan Eich]

On Sep 27, 2009, at 2:57 AM, Maciej Stachowiak wrote:

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.


The discussion (the thread started here:

https://mail.mozilla.org/pipermail/es-discuss/2009-May/009168.html

) brought out this and other points. Having to reify an object as a  
property value, only to invoke it somehow (call or construct), often  
makes excess garbage, hence this proposal's call-property and  
construct-property hooks.


But your point is good too: sometimes you already have an object and  
it needs to act as a callable or constructor.


A mirage-based dark-horse candidate proposal will (I hope) deal with  
both cases.



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.


Preferably before anything is prematurely standardized...


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.


I said that at ICFP 2005 in answer to a question (from Simon Peyton- 
Jones, IIRC), so I agree.


But beyond separating functions from constructors, the ability to  
spread array elements as positional actual parameters, and to deal  
with |this|-binding separately for functions, help to untangle the  
multiple strands of magic woven into function objects in ES so far.  
Combining constructors and functions is not the only case of unwanted  
entangling.



I'm musing a bit here, bear with me. If we only hack incrementally,  
and preserve backward compatibility with frankly dumb (or merely  
hasty) design decisions (many mine!) then we'll probably make less  
progress than if we try to rationalize old and new in a better  
systematic design.


That's a little too abstract for me to tell if I agree or not.


Shortest-path evolution can walk uphill only a little bit at a time,  
and get stuck at local minimal points in a design space, when over the  
big hill is a much better, richer valley to evolve in. This path  
dependency problem bits many real-world systems.


I experience this point as hard and painful, like concrete -- it' s  
not abstract. I've been around too long to ignore it, as it's all  
around us on the web, and it has been since 1994 if not earlier.


Compatibility concerns in the form of graceful degradation or  
progressive enhancement are not unmixed blessings. More coherent  
stacks from Microsoft, Adobe, and Sun can rightly claim to solve  
problems more cleanly and simply than the web. Of course these stacks  
have other problems, mainly from being single-sourced if not  
proprietary, but also from not progressing compatibly, and for other  
reasons I won't digress on.


But there's no point pretending the Web (ES, DOM, etc.) is an example  
of a well-designed toolkit for building user-facing distributed apps!


/be

Re: Web IDL Garden Hose

[Brendan Eich]

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!

/be

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

[Brendan Eich]

On Sep 26, 2009, at 11:28 PM, Maciej Stachowiak wrote:

There are methods, but I'm not optimistic that they will cause  
property reflection to wither.


getItem/setItem/removeItem/key/clear methods, plus .length -- not a  
balanced name-set stylistically, but usable to avoid collisions (my  
key is named 'key', heh).


Agreed it looks nearly hopeless to herd developers toward always using  
these methods instead of .myKey, etc.



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.  I don't think anyone has implemented that yet.


Horses still out the barn door and we didn't close it yet, I'm not  
sure who to blame except "us" (would be barn-door closers, possibly in  
charge of those horses -- but perhaps they're not even ours!).



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.


I'll see what the relevant Mozilla WebAPI hackers think, if they're  
not reading this thread. At this point I suspect it is "too late", in  
the sense that we'd be taking risks with plaform compatibility we  
don't accept in our release version/compatibility plan.




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".



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.


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 
.


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.



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

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

[Brendan Eich]

On Sep 26, 2009, at 11:16 PM, Cameron McCormack wrote:


OK, that is indeed what I’m hearing from you guys.  “Host objects may
implement these [internal] methods in any manner unless specified
otherwise” in ES3 doesn’t sound like it’s particularly discouraging of
the different behaviour that Web IDL prescribes.


That is regrettable ES1-era language, written to accommodate the "host  
objects" found prominently in IE due to too-low-level COM integration.  
It should have come with color commentary advising against exploiting  
the barn-door-sized loopholes.




Why is functionality that isn't available through native objects
needed?


For web compatibility, really.


Web Storage is a recent example of something other than web  
compatibility at work. Imitation of what went before, keystroke- 
optimization to use the short property reference expression instead of  
get/put/remove methods, or both, AFAICT.



Ignoring the legacy issues, assuming we have ES5 to build on, then  
yeah

it seems like most things can be done (from Maciej’s quick analysis).
The array like objects do seem like a useful pattern for authors to  
use,

though.


Seems like everyone agrees Array-likes are not the issue.

/be

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

[Brendan Eich]

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.



and I think now everyone (including I believe Microsoft) has  
implemented the spec behavior. See prior discussion thread here: .  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.




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?

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 seems winning since developers want not only sane typeof,  
but .apply/call/bind.


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 bug on file to fix our built-in functions (Date  
methods, etc.) to lose [[Construct]] and .prototype. I'm not sure of  
v8's plans.


First-class syntax for defining such non-constructor functions is  
elusive. ;-)



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.


Is there anything specified via WebIDL that must be a constructor but  
not a callable?


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).




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


Definitely.


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.


As an aside, the strawman for 'constructor' makes at least Mark Miller  
and me want to unify 'class' and 'constructor' -- we don't want both,  
and Harmony needs something already called class for several reasons,  
one of them to model built-ins in ES1-5.



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.

/be

Re: WebIDL

[Brendan Eich]

I did not single out Replaceable in my efforts to understand.


Sure, but it is certainly odd and I wanted to recount some of the  
history, just so you'd know not to over-attend to it. ;-)


WebIDL comes from OMG IDL, much of the precedent is documented in  
various online sites, CORBA books, etc. It's not all that strange or  
bad, just a bit "'90s big OOP system" in flavor.


To understand it all takes a while, and Maciej allowed as how some of  
it could be cut without harm. Maybe we should start there.


/be

Re: WebIDL

[Brendan Eich]

On Sep 25, 2009, at 11:43 PM, Yehuda Katz wrote:


Do we disagree that it is a worthy goal to have a specification that
can be understood without having to take a while? I certainly
understand the utility in using something with precedent like IDL (for
implementors). Perhaps the IDL version could be part of an addendum,
and something


What "something"?



with less historical and conceptual baggage be used
inline? Or is that too much work?


Do the work, it's the only way to get to "something" and make it stick.

I don't think we should continue cross-posting like this to three  
standards groups' lists. Yes, old and layered specs are often complex,  
even over-complicated. No, we can't fix that complexity in the case of  
WebIDL by rewriting the extant interface descriptions in ES. As Maciej  
noted, doing so would cost ~10x the source lines, and beyond verbosity  
would be incredibly unclear and error-prone.


Those who seek to replace WebIDL must first grok what it means, how it  
is used. To do that, I suggest trimming cross-posts, and even before  
replying, reading up on the relevant WebIDL docs and list. Once you've  
braced yourself for this process, and gotten further into it, I am  
sure that a Q&A process will work better.


You are absolutely correct that the specs are complex and  have gaps.  
Every engineer who has worked on a web-compatible browser has had to  
learn this the hard way. I don't expect the Web to be "done" but I do  
think better specs will close gaps and reduce some of the complexity  
over time. That's the hope behind this overlong, cross-posted thread,  
anyway. I'll shut up now.


/be

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

[Brendan Eich]

On Sep 25, 2009, at 4:57 PM, Maciej Stachowiak wrote:


On Sep 25, 2009, at 1:18 PM, Brendan Eich wrote:

So if you are doing more ArrayLike interfaces, let's keep talking.  
Don't let at least my catchalls-considered-harmful statements stop  
progress on ArrayLikes.


Perhaps when catchalls are considered for ECMAScript, there could b  
a way to encapsulate the specific pattern of index access, so you  
can have magical getters and setters for all index properties  
(integer numbers in range to be an array index) without having to  
install a full catchall for all properties.


Good point -- implementing array-likes via catchalls has been on our  
minds since the ES4 "meta" days [1], although we never split hooks  
based on property name being non-negative (possibly also <= 2^32 - 1  
-- or is it <= 2^32 - 2?!).


With WebIDL folks' help we will probably take down ArrayLike first,  
without going whole-hog for catchalls. The "catchalls climb the meta  
ladder" problem is more profound than the index/length magic (even the  
awful uint32 domain) of array-likes. I agree with Waldemar, we should  
make progress on array-likes without getting hung up on catchalls.


/be

[1] http://wiki.ecmascript.org/doku.php?id=proposals:catchalls

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

[Brendan Eich]

I will stop the over-citing madness here and now :-P.

The struggle to formalize ArrayLike, which seems like a common goal  
for ES the core language and for WebIDL's ES bindings, makes me want  
to give an exception to the "catchalls considered harmful for new  
interfaces" injunction. I agree that indexing into array-likes, with  
no liveness magic, seems containable and desirable. ES folks haven't  
nailed down ArrayLike yet (our fault) and we would benefit from  
collaboration with WebIDL folks here.


So if you are doing more ArrayLike interfaces, let's keep talking.  
Don't let at least my catchalls-considered-harmful statements stop  
progress on ArrayLikes.


I expect some ES folks may demur now :-).

/be

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

[Brendan Eich]

On Sep 25, 2009, at 12:08 PM, Jonas Sicking wrote:

On Fri, Sep 25, 2009 at 9:56 AM, Brendan Eich   
wrote:

My positions are:

1. WebIDL, the bird in the hand (I agree with Sam: go invent  
something

better, come back when you're done).

2. Don't keep perpetuating catchall patterns, they are confusing for
developers and costly for implementors and static analysis tools,  
even if

implementable in some future ES edition.

3. Don't care.


Regarding 2. How do you feel about index accessors? I.e. for example  
you can do:


myNode.children[5]

which returns the same as

myNode.children.item(5)

This seems equally impossible to implement in ECMAScript, but is
something that I think is helpful to authors so not something that I
want to stop adding to new interfaces.


Good point. I have mixed feelings, to be honest. See the ArrayLike  
thread on es-discuss:


https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html

and followups. The one from Travis Leithead of Microsoft at:

https://mail.mozilla.org/pipermail/es-discuss/2009-May/009363.html

links to http://dev.w3.org/2006/webapi/WebIDL/#es-sequence, which has  
words about an "Array host object":


http://dev.w3.org/2006/webapi/WebIDL/#dfn-array-host-object

This is new and different from the legacy collection/nodelist stuff,  
which we can't change. Is it the new-model solution for index  
accessors, or are you still wanting to make live "tree cursors" with  
indexed getter and setter catchalls?


The live tree cursors always seemed like a mixed bag at best. Folks  
want to use Array generic methods on them, and sometimes find the  
liveness a problem. I've not heard anyone saying the liveness was a  
crucial win.


/be

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

[Brendan Eich]

Three distinct topics are being mixed up here:

1. Whether to use WebIDL or some unproposed alternative.

2. Whether to use catchall patterns in new WebIDL-defined interfaces.

3. Whether the JS WebIDL bindings should be standardized by Ecma or W3C.

The straw man (0. Whether to remove catchall patterns from existing  
WebIDL interfaces required for backward compatibility) is nonsense and  
I'm going to ignore it from here on.


My positions are:

1. WebIDL, the bird in the hand (I agree with Sam: go invent something  
better, come back when you're done).


2. Don't keep perpetuating catchall patterns, they are confusing for  
developers and costly for implementors and static analysis tools, even  
if implementable in some future ES edition.


3. Don't care.

I differ from Mark on 3, but that's ok. What is not ok is to waste a  
lot of time arguing from divergent premises that need to be unpacked  
or else let alone for now, when we could be collaborating on concrete  
issues such as split windows, execution model, catchall policing, etc.


Mark's Joe with his JoeLang bindings for WebIDL vs. Anne's point about  
the primacy of JavaScript bindings for WebIDL-defined interfaces is  
not going to lead to rapid agreement on putting the ES WebIDL bindings  
in Ecma vs. leaving them in W3C. It's a rathole, IMHO.


Both points of view have merit, but precedent and possession matter  
too, and Ecma can't plausibly fork or steal the binding spec. We're  
trying to collaborate, so let's get on with that hard work instead of  
trying to assail one another with principles that can't encompass the  
whole picture.


Hope this helps,

/be

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

[Brendan Eich]

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

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.


Are invited experts time-bound in some way? We learned in Ecma that  
experts were to be invited to one meeting only.



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.


I've been writing my own opinion, qualified that way. Other TC39  
members should opine. I really don't want to grab a spec from w3c,  
even if there is some concern about expertise being split awkwardly.  
I'm interested in fixing the split, not where the spec or specs end up.


ISO and Ecma will insist on some degree of self-contained status for  
the ES specs. We refer to Unicode and IEEE-754 but for foundational  
things like the global object(s) and the execution model.



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.


Yes, the foreseeable future wants backward compatibility. But we might  
find a better binding for new APIs, and possibly recast old ones  
(minus old stuff that is not actually used much) in new, more usable  
clothing.



If ES5 has requirements on this that match ES3, then it has a  
requirement that Firefox, Safari and Chrome (and I think Opera?)  
are all violating, and likely will continue to violate for the  
foreseeable future. That seems like a problem. (Unless we convince  
ourselves that the split global object pattern somehow doesn't  
actually violate the ECMAScript spec.)


It's a violation, for sure, but no one will be struck down by  
lightning. We can live with it a bit longer.


Well, it seems bad to me for the spec to state a requirement that  
won't be followed.


Yes, it's bad. Now what?


Specifying more about multiple global objects would be good, but I  
think it's not a case where current browser behavior violates the  
ECMAScript spec, so it's not really the same issue.


Multiple globals as in frame or window objects, probably not. Although  
IE does some very strange dynamic scoping in its window.eval  
implementation, or did -- see


http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.x_working_docs&cache=cache&media=resources:jscriptdeviationsfromes3.pdf

This is not going to be standardized, so it's an IE bug to fix (if not  
fixed already).


There are edge cases to do with split windows and whether you get  
exceptions or !== true results, but these are the real multiple global  
objects issue I had in mind. Even ignoring multiple frames or windows,  
just a single WindowProxy with more than one Window global object is  
outside the ES specs, which do not admit more than one global object.



WindowProxy and Window go a step beyond multiple globals, of  
course, splitting each global in two (or one proxy and one or more  
globals under navigation with cached history).


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.


That's backward: the outermost scope chain object must be the ES  
global object, what HTML5 types in WebIDL as a Window.


It's the WindowProxy for that Window (and others forward and back in  
session history) that must be bound to |this| in global code, contrary  
to ES.



The main downside is that this is more loose than is needed and  
could technically allow crazy unreasonable things.


This is not tenable -- the WindowProxy is shared among multiple  
globals and possibly cross-origin scripts loaded in multiple globals.  
Those globals not current but rather "back" and "forward" in the same  
WindowPro

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

[Brendan Eich]

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  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:    .


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 fruitfully without more detail.


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



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?


No, nothing was changed in ES5 and it is not clear without more  
discussion with various experts active in whatwg, w3, and Ecma what to  
do.


Since you asked, I think you make the case that we should collaborate  
a bit more closely.




I know the feedback was passed along.


Yes, but describing the