Re: [widgets] Zip vs GZip Tar

On 30/04/10 6:36 PM, Ian Fette (イアンフェッティ) wrote:
> Am 30. April 2010 00:26 schrieb Marcos Caceres <
> <>>:
>     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
>     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

I would say widgets are as above, but...

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

But this is also true. Though required <feature>s in the widget config 
document could cause a widget to be treated as unsupported. So 
streamability would only work for a particular subset of widgets.

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

I agree with you. I don't think this is a bikeshedding discussion 
either. Lets talk more about use cases and requirements.

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

It's no more difficult than installing a browser I guess. I won't say 
"the tools will save us".

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


1. it's too late for P&C because the W3C process forbids us from adding 
more stuff to it. Please see:

There is just no way we are dropping that back to Working Draft. There 
are too many people that have implemented the spec and it serves a 
different use case.

2. Please forget the whole widgets thing. Lets just focus on use cases 
and requirements. We can certainly define a "Streamable Packaging Format 
For Web Applications" or whatever we want. If it uses part of Widgets, 
then yay! if not, who cares.

Marcos Caceres
Opera Software

Received on Friday, 30 April 2010 17:32:07 UTC