W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [Component Model] Decorator Challenges

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Mon, 28 Nov 2011 09:18:13 -0800
Message-ID: <CADh5Ky2ZuGrEGS_OkO4R_j35EvPEOFDnouA+QnvTsayhRi+9ag@mail.gmail.com>
To: Roland Steiner <rolandsteiner@google.com>
Cc: public-webapps <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>
On Thu, Nov 24, 2011 at 6:40 PM, Roland Steiner
<rolandsteiner@google.com> wrote:
> On Wed, Nov 23, 2011 at 08:05, Dimitri Glazkov <dglazkov@chromium.org>
> wrote:
>> Even if we attempt to separate the state of a decorator from the
>> element and its document using an iframe- or worker-like machinery,
>> we’ll still have similar issues of managing decorator instances that
>> are no longer relevant, but don’t know that yet -- in addition to the
>> performance costs of such high-isolation approach.
> I don't quite follow what you mean with the above - could you go into more
> detail on this point? E.g., why would it be a problem if a worker-like
> decorator that got detached sits around for a little while longer, doing
> last timeouts and other stuff that no longer really matters?

In case of total isolation, we totally could spec a clean shutdown
process where the timers are cancelled and messages are dropped

> (FWIW, I'm also not convinced that it'd have to have high performance
> overhead - in the best case it could be as little as just one more level of
> indirection.)

The startup time of a worker is non-trivial. Similarly, the shutdown
won't be trivial. And the memory footprint of a worker isn't trivial
either. If we're aiming for decorators to be fast and lean, we'll have
to think of ways around those costs.


> Cheers,
> - Roland
Received on Monday, 28 November 2011 17:19:06 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC