On 30 Apr 2010, at 18:46, Ian Fette (イアンフェッティ) wrote: > Marcos, Chaals, fair points. I can't honestly say that we are looking to > implement this spec at this point,
I saw a very nice W3C Widgets implementation on Android the other day ;-) > 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. Certainly sounds like an interesting UC for v2 > > -Ian > > Am 30. April 2010 10:31 schrieb Marcos Caceres <marc...@opera.com>: > > > 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 >
