Re: [toolbox] Extended Attributes

[Maarten S. <maa...@xs...>]

On 27 Jun 2005, at 16:21, J=E9r=F4me Laurens wrote:

> Le 24 juin 05, =E0 22:56, Maxwell, Adam R a =E9crit :
>
>> I've tried setting xattrs and moving a text file onto an NFS =20
>> volume; the attributes were preserved when moving them back and =20
>> forth, which is good.  However, opening and saving the file in =20
>> TextEdit lost the attributes, which is unfortunate.
>>
>
> Indeed.
>
> I guess mail will not send this xattrs too...

or an ftp transfer, or http for that matter. I'm not sure about sftp/=20
scp though, they might support xattrs. But I guess there are a =20
thousand ways to loose your metadata (cue music here).

> I think the best policy is to never rely on such attributes.

I wouldn't put it that way: when present, they can be trusted, when =20
not available they must be reconstructed somehow.

> Also, for extended file attributes, the best way seems to consider =20
> at the same time xattrs, resource fork and external location when =20
> possible.

I assume with external location you means something like a project =20
file or a wrapper. Warning: attempt to get you to write an article =20
ahead: Could you create some overview of what your idea of a TeX =20
wrapper is (and maybe more importantly: what it isn't. I think this =20
article should address the context in which wrappers will be used (in =20=

your vision)).

> That way, we hardly break the whole metadata design when moving =20
> files around, and can retrieve at least partly the metadata.

I'm going to make a bold statement here: all the metadata is already =20
in the TeX sources, and can be reconstructed from there. (why are we =20
getting so excited about it then ;)

- The encoding is indicated in the master file \usepackage[latin1]=20
{inputenc} is fairly unambiguous, and Context has similar statements.
- The master file can be found by searching through a directory tree =20
(including looking 'up' the tree), again this works for both LaTeX, =20
TeX and Context. It may be relatively slow, and I know of cases where =20=

it fails (where a file could be processed stand-alone, or included, =20
or documents that can be included in more than a single master. The =20
current metadata approaches will not handle those cases either).
- One can try to determine the engine by looking at the command =20
sequences: \begin{figure} is indicative of LaTeX, \startfigure hints =20
at context (though its multiple input language support makes things a =20=

bit harder).

OK, doing away with metadata is not a good idea, but not all is lost =20
if they become separated. At the moment I'm still in favour of using =20
comments to indicate some key elements (character encoding, an =20
indication of the master file, the core engine, and then some) or a =20
property-list file to hold that info (the latter may become out of =20
sync, so that is an issue). For things like navigation markers, I =20
strongly prefer the in-source option, because it allows me to put a =20
marker in very quickly.

> Needs some further thinking before implementation.

Certainly, if only because you can bet that Apple will deliver some =20
Cocoa interface for xattrs later on. We should certainly strive to =20
keep it modularised, so that it can be replaced easily with whatever =20
Apple delivers.

Maarten=