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

Re: [widgets] Zip vs GZip Tar

From: イアンフェッティ <ifette@google.com>
Date: Fri, 30 Apr 2010 09:36:05 -0700
Message-ID: <AANLkTiknmHL7hYE6IeCoYEzTtjcjMWxXJWz-XaUtSHxn@mail.gmail.com>
To: Marcos Caceres <marcosc@opera.com>
Cc: timeless <timeless@gmail.com>, Gregg Tavares <gman@google.com>, Arve Bersvendsen <arveb@opera.com>, Web Applications Working Group WG <public-webapps@w3.org>
Am 30. April 2010 00:26 schrieb Marcos Caceres <marcosc@opera.com>:

> Hi Ian,
> On Apr 30, 2010, at 8:09 AM, Ian Fette (イアンフェッティ) <ifette@google.com>
> wrote:
> 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.
> I don't know who is feeding you ideas about "politics", but there is
> nothing contraversial about the Widget specs. If you know something I don't,
> then please tell us. Also, last I checked there were over 40 companies
> backing widgets. Just because Google ain't backing them right now does not
> mean they are going nowhere.
> 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."
> If this was true, then why does chrome  use Zip for browser extensions?
> They are almost exactly the same as W3C widgets in every way.

a) there's not a sense of starting to render an extension before it's
b) and it's installed or not installed atomically.
c) they are installed and updated in the background, not necessarily
embedded on a page

On the other hand, a widget on a page could certainly be rendered

> 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.
> We care about making a generic packaging format that everyone can make (not
> just people on *nix).

And I was not advocating for a specific algorithm, I was objecting to
someone taking a valid criticism with technical backing and calling it

fwiw though, taking tar/gzip as an example, it is not exactly hard for a web
author to deal with a tar file.

> Google has been actively encouraged to participate in this work from the
> beginning. It's not our fault Google didn't want to contribute this as a use
> case.
No, it's not. That doesn't mean that valid criticisms should be dismissed as
bikeshedding, or that people should cling to a notion of being "too late".
We aren't clinging to Gears saying it's too late, we're not even really
clinging to Web SQL DB - we are actively moving forward on Web Indexed DB
and are very involved in discussions on how to improve the offline storage
situation. So, frankly, I really don't buy the "it's too late" argument for
any of this.

> However, for someone (or an organization) that takes performance very
> seriously, it is frankly a bit insulting to call something like this
> bikeshedding.
> You are confusing the use cases of widgets and seem to be frustrated
> because they were not built around your needs. The P&C spec is what it is
> because it addresses a clearly defined set of requirements (search for
> "widget requirements").
> I still don't see why we can't create a "streamable packages" spec around
> your use cases?  They don't even need to have any association with widgets.
> -Ian
> Am 29. April 2010 20:04 schrieb timeless < <timeless@gmail.com>
> timeless@gmail.com>:
>> 2010/4/30 Ian Fette (イアンフェッティ) < <ifette@google.com>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 16:36:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 14:36:43 UTC