Re: [widgets] Zip vs GZip Tar

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.

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