Hi Ian,
On Fri, 30 Apr 2010 18:36:05 +0200, Ian Fette (イアンフェッティ)
<ife...@google.com> wrote:
Am 30. April 2010 00:26 schrieb Marcos Caceres <marc...@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
