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/
