Re: [widgets] Zip vs GZip Tar

Marcos, Chaals, fair points. I can't honestly say that we are looking to
implement this spec at this point, and certainly I am not the type to raise
a formal objection, so please don't misinterpret this as "I think this spec
needs to go back to an earlier stage in the formal process." I also
understand that once things start to ship in implementations, they are
harder to change. I guess what irked me was that there was what I saw as a
valid point being raised and dismissed. I do think that having a packaged
format that is streamable would be useful, especially if you wanted to host
these widgets inside of any container / page that may load the widgets
dynamically (e.g. iGoogle as an example of a web page loading what are
essentially widgets). I would agree that given your existing implementors
and the use cases they are targeting, it is likely not important enough to
cause strife to existing implications and cause them not to work. My hope
was that perhaps it could be considered and a backwards-compatible mechanism
could be found. e.g. today browsers and servers negotiate what encodings
they accept, one could imagine a similar negotiation taking place prior to
whatever widget is there being served up. I think it is something to
consider, at the very least for v2.

-Ian

Am 30. April 2010 10:31 schrieb Marcos Caceres <marcosc@opera.com>:

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