W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [widgets] Zip vs GZip Tar

From: イアンフェッティ <ifette@google.com>
Date: Thu, 29 Apr 2010 23:09:51 -0700
Message-ID: <AANLkTinCe1SA_VGuYpxuhgE62jofy94zqo3JxDs1k1yO@mail.gmail.com>
To: timeless <timeless@gmail.com>
Cc: marcosc@opera.com, Gregg Tavares <gman@google.com>, Arve Bersvendsen <arveb@opera.com>, Web Applications Working Group WG <public-webapps@w3.org>
Disclaimer: I really don't care about this particular spec given
the politics and think that it is likely not to go anywhere as-is. So take
my feedback for what it's worth.

This is not bikeshedding, nor are many of the previous threads that have
brought up issues with this spec and body of work in general. This is not "I
prefer my favorite random compression algorithm," this is "a serious
performance issue is caused for loading any large widget that is packed in
such a manner because we can't do anything until the entire file is
downloaded." Maybe some people don't care about performance, and if a lack
of concern for performance is part of the use cases, then such a decision is
perfectly valid according to the use cases. However, for someone (or an
organization) that takes performance very seriously, it is frankly a bit
insulting to call something like this bikeshedding.


Am 29. April 2010 20:04 schrieb timeless <timeless@gmail.com>:

> 2010/4/30 Ian Fette (イアンフェッティ) <ifette@google.com>:
> > I remain perplexed by the state of "the spec is feature complete and
> looking
> > for implementations" -> potential implementors saying "the spec has X,Y,Z
> > flaws" -> "sorry, the spec is feature complete. We're looking for
> > implementations." At this rate, it's not clear to me what implementations
> > it's going to get.
> > (speaking as an individual here, and not a representative of Google Inc,
> > Google Chrome Team, or necessarily even as a member of webapps WG.)
> > -ian
> Roughly there are already implementations.
> A spec at this point is looking for implementers to say "this is not
> implementable because of a bug or fatal error".
> It is not looking for an implementer to say "we don't like X, why not
> randomly tweak the bike shed color from red to hot pink".
> If it turns out that using a red bike shed will cause people to crash
> because they're all red-green color blind and can't see the red shed
> in front of the flat green background, then perhaps painting the shed
> hot pink is a necessary step to delivering the bike shed.
> But given that there are already implementations which have shown that
> a red bike shed works, then just asking to paint the bike shed hot
> pink doesn't work at this point.
> fwiw, I came two years ago and was already too late to change the
> signature mechanism. You're coming two years after I came late and
> asking to change the packaging mechanism. Your argument is that the
> bike shed color should be hot pink because you like it (it would be
> nice if you could use it on some beach somewhere in some condition
> which was not part of the requirements capture). My argument against
> the signature mechanism was based on canonicalization problems, and
> they tried to address that (not my hand waving, just the problem) by
> tweaking the spec, not by throwing out the entire model.
Received on Friday, 30 April 2010 06:10:23 UTC

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