Re: [widgets] Zip vs GZip Tar

Hi Ian,

On Apr 30, 2010, at 08:09 , Ian Fette (イアンフェッティ) wrote:
> 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.

If you have references to back this statement, they would be appreciated.

> 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." 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. However, for someone (or an organization) that takes performance very seriously, it is frankly a bit insulting to call something like this bikeshedding.

A standard is, in many ways, not very different from a piece of software — sometimes you need to freeze to make a release. That's the state that P+C is in right now. You can think of it as us only accepting patches against crashers.

P+C doesn't support streamability because no one asked for it. I think that it's pretty much a very good thing if when no one asks for a feature and no one volunteers to work on it then it doesn't get included in the specification.

I suspect that P+C uses Zip for the very same reason that Chrome extensions use Zip; after all they have very strongly related requirements, the primary difference being P+C's focus on broad interoperability.

This does not at all mean that streamable widgets are out. If there's interest, if there's a good use case (or better, several), and if there are people willing to work on it then we can certainly look into solutions.

Gregg: are you looking at P+C for a potential broader packaging system? (Your OP seemed to indicate something along those lines).

-- 
Robin Berjon - http://berjon.com/

Received on Friday, 30 April 2010 09:45:28 UTC