With the introduction of custom elements I find myself more and more
interested in script that is tightly coupled to DOM nodes but that can be
safely spun down when that node is GC'd (not just lifecycle "removed").
This could be achieved by having a callback on weakmaps or some way to hook
into the destruction phase of a dom element's lifecycle ( this seems
messier from an authoring standpoint ).

Perhaps somewhere in the middle would work, something like a regular map
but that also pays attention to the ref count changes of key and an author
can hook in with a callback that effectively means "reached 1 ref".


On Tue, Nov 12, 2013 at 10:49 AM, Brendan Eich <[email protected]> wrote:

> Mark S. Miller wrote:
>
>> Much of the early Actors research
>> DEC SRC Network Objects
>> RMI
>> Original-E before I arrived at Electric Communities
>> Midori
>> Orleans
>> AmbientTalk
>> Cap'n Proto
>>
>
> Mark (and Tom, cc'ed), please take this as sincere feedback from a fan --
> I mean this in the best possible way:
>
> I remember the mid-late '80s to '90s RPC wars, Sun RPC vs. Apollo RPC, Ken
> Birman et al.'s work at Cornell (and on Wall Street back end systems),
> CORBA, Java RMI, all that. I have some scars myself.
>
> That history, plus some of the names dropped above, form a large
> super-counterexample in my opinion. Lessons painfully learned:
>
> * One cannot ignore network latency and partitioning.
> * Sync RPC is the wrong model (it already yielded to async calls,
> futures/promises, and the like).
> * Weak consistency (I know, people hear "CAP" and give up too much) won,
> which surprised some.
> * As Mike Stonebraker observes, hardware trade-offs flipped upside down
> with a vengeance.
>
> The example of the Web, messy as it is, shows a success story so big that
> we live inside it without often being conscious of it, like happy fish in
> bubbly water. True, it's still too client/server, too "stateless" with
> login and session state built into silos on server networks, too subject to
> dreary XSS and CSRF threats. I agree it is not the full distributed system
> that it should be.
>
> But are we really going to build distributed-GC systems at Web scale, with
> mutual suspicion and accidental failure accounted for?
>
> It's as far as I know fair to say that Erlang is used in "mutual trust"
> settings, even though "trust" means "assume failure happens, deal with it
> as part of the design". So, Erlang is good for systems that distribute
> across a server peer-to-peer network, but not yet demonstrated as good for
> client/server/p2p/Web in full. Perhaps it or a language/system it inspired
> (Go, Rust) will break out across the Web, but this is in the future.
>
> If we must go once more unto the distributed-GC breach, it would give me
> more confidence to see some literature outside the 
> OCap/RPC/tightly-coupled/research/unshipped-OS
> world, which AFAIK has never been demonstrated at anything approaching Web
> scale.
>
> Something built on the Web and even deployed to cite along with the listed
> names above would be better. What cowpath could we pave?
>
> /be
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
- Matthew Robb
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to