RE: .webfont Proposal 2

On Wed, 2009-07-15 at 21:06 +0000, Sylvain Galineau wrote:

> >-----Original Message-----
> >From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf
> >With all due respect to Bert Bos, I hope that
> >you will instead reconsider using MIME.   For
> >most practical purposes, you can regard MIME
> >format as a compressible "directory archive"
> >so most reasons you might have for choosing a
> >file archive format are also reasons for choosing
> >MIME.

> Many successful file archive formats do not choose MIME e.g. JAR files, which
> bind together binary files together with one or more manifests and XML descriptors.

Yes (and, I'm aware of that).


> Such solutions work perfectly well in practice. I can create, read and edit a zipped
> file archive right now on any of my machines running on three different OSs. 

Such solutions work well for some applications, 
that's true.


> I honestly don't
> know how I would convert a directory to MIME on any of them or why I'd even want to do it;

You normally would not or want to do so.  Normally
you would want to use a file archive tool and format
that records file meta-data such as modification time.

MIME is a good choice for a meta-data wrapper, though,
because it is flexible, already extensible in an orderly
manner, and parsimoniously consonant with the design of HTTP.



> nor did anyone ever send me a file archive as a collection of MIME parts vs. a single zip.

Typically people send files as email attachments.  Your
Mail User Agent is acting as the encoder / decoder,
as I'm sure you are aware.


> That it could technically be done that way does not warrant
> avoiding a common, familiar and quite usable pattern.

MIME is also a familiar and quite usable pattern,
with the relative advantages I've described.  I'm
not sure why you did not take up that relative comparison.

Either solution can "technically work" but they
make distinct trade-offs.  I've explained why I think
the MIME trade-offs are more appropriate to the design
context.


> So, fwiw, I don't think parsing and decoding MIME adds
> any value here 

As I explained, among the relative advantages are
parsimony (c.f. HTTP), orderly extensibility, and 
the avoidance of unneeded meta-data fields.


> and I don't buy that
> 'consonance with the design context' mandates standard
> internet mail encoding for web fonts at all. 

It is clear that you do not but why or why others
should agree with you is unclear.

> The proposed solution makes it much simpler to
> create these files, edit them, and generally
> handle them both manually or programmatically.

Do you envision, for example, people creating
a font for web use, writing the metadata file,
and then using, say, a "zip" program to package
the results for distribution on the web?

Among the disadvantages of such a plan is that on
most systems, the ordinary way of creating such a 
file archive or unpacking one will record and restore
file attributes such as a user ID.

It is a simple enough matter, on the other hand, 
to write an "encode/decode" program pair for a 
MIME format.


> Lastly, I don't think a web font format should require
> client software that wishes to support them to include
> a MIME parser (HTTP is MIME-like but not strictly 
> MIME-compatible). 

I am at a bit of a loss as to why you think
MIME is unacceptable while, say, zip is not.


> Granted, this may be colored by a former
> life maintaining a server-side
> MIME parser for a webmail system.

OK.



> Ultimately, the priorities should be to 1) define
> structure and content 2) secure agreement and 
> commitment from implementers, foundries etc.
> How the data is serialized on the wire/on disk
> is for all intents and purposes orthogonal to these
> priorities and less interesting imo.
> At a minimum, requiring MIME or XYZ or FOO encoding
> will not make it any easier to secure agreement on
> content or support so it shouldn't matter at
> this stage.

It is unclear what you propose to form agreement
about.  The phrase "structure and content" is vague
and you seem to specifically exclude serialization
from being an aspect of "structure and content".

Perhaps it would be more effective if you offered up
a specific proposition to which implementers, foundries,
and the larger community, could express agreement or
disagreement.

-t

Received on Thursday, 16 July 2009 01:29:00 UTC