On 30/04/10 6:36 PM, Ian Fette (イアンフェッティ) wrote:
Am 30. April 2010 00:26 schrieb Marcos Caceres <marc...@opera.com
<mailto:marc...@opera.com>>:
Hi Ian,
On Apr 30, 2010, at 8:09 AM, Ian Fette (イアンフェッティ)
<ife...@google.com <mailto:ife...@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
