Re: [widgets] Zip vs GZip Tar

Hi Ian,

On Apr 30, 2010, at 8:09 AM, Ian Fette (イアンフェッティ)  
<> 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  

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

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.

> 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 <>:
> 2010/4/30 Ian Fette (イアンフェッティ) <>:
> > 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 07:27:51 UTC