Re: [widgets] Zip vs GZip Tar

Hi Ian,

On Fri, 30 Apr 2010 18:36:05 +0200, Ian Fette (イアンフェッティ)  
<ifette@google.com> wrote:

> Am 30. April 2010 00:26 schrieb Marcos Caceres <marcosc@opera.com>:

... performance matters, GZip Tar might be better ...

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

Indeed. I think that comment was out of line really, and trust you have or  
will receive a private apology for a comment made on a bad day.

> or that people should cling to a notion of being "too late".

Shipping (for specs like software) is a feature, and that means that there  
needs to be some notion of a feature freeze.

It might be that the specification fails, and only in a new version which  
changes the packaging system gains the traction it needs. But I think it  
is a fair argument that the current version has shown itself to be widely  
deployable and sufficient for the needs of those who actively implemented  
and promoted it.

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

It's not too late to start version 2. If you are actually implementing,  
and your data shows that there is a really good reason to switch, then it  
might not be too early, either. But having got consensus of what seems  
like a reasonable number of implementors (and given the number of similar  
projects which made the same choice) and got the spec to where it is  
"stable, ready for testing and expected not to change unless we discover  
some dire problem" it seems that the argument raised in favour of tgz over  
zip is not sufficiently serious to warrant a return to last call and a  
rewrite of the current toolset, tutorial documents, and so on.

Draft standards should not be bound by experimental implementations, but  
nor should they pretend that all implementation before the magical (and in  
large part arbitrary) day on which the specification is finally "finished"  
are irrelevant. The threshold for justifying a change increases as the  
standard and the implementations mature. And in this case we are talking  
about something that has been pretty stable for a few years.

You can, if you think that it is really important, raise a formal  
objection to the spec going forward with Zip, or ask your AC rep  
(currently TV Raman) to object when the spec is in Proposed  
Recommendation. You can also propose a version 2, which expands the  
possible set of package compressions (or even renders version 1  
incompatible). As the Web changes, we standardise what is there - so if  
reality shifts and all packaging is using tgz we would be stupid not to  
make a new version that does that.

But it seems there is little support in the group to change the current  
document this way at this stage of the process. Like WebSQL, it could be  
more or less abandoned if nobody was really keen to support it going  
forward, but that appears not to be the case.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Friday, 30 April 2010 16:57:41 UTC