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 <marcosc@opera.com
> <mailto:marcosc@opera.com>>:
>
>
>     Hi Ian,
>
>     On Apr 30, 2010, at 8:09 AM, Ian Fette (イアンフェッティ)
>     <ifette@google.com <mailto: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

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.

Again,

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

http://www.w3.org/2005/10/Process-20051014/tr.html#cfi

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