Re: [widgets] Zip vs GZip Tar

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

Because
a) there's not a sense of starting to render an extension before it's
installed,
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
optimistically.


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

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