Bundles, a draft specification

[Mildred]

Le Fri 07/09/2007 à 17:55 Thomas Leonard à écrit:

> No system is reliable if it's not supported. For example, in your 
> proposed system if a user moves or renames a file using a non-bundle-
> aware program then the type information will get out-of-sync. Types
> will also be lost when copying out of a bundle.
> 
> On the other hand, existing tools should preserve attributes:
> 
> $ touch my-web-page/image
> $ setfattr -n user.mime_type -v image/png my-web-page/image        
> $ mv my-web-page/image my-web-page/picture
> $ getfattr -n user.mime_type my-web-page/picture 
> # file: my-web-page/picture
> user.mime_type="image/png"
> 
> I'd prefer to see wider support for the existing mechanisms than
> trying to create a new system. That might mean persuading
> distributions to enable extended attributes by default.

You're right. Maybe there is no point trying to create such artificial
structure. But the major problem to extended attributes, is that if you
copy/move a file which has such attributes to a filesystem that do not
support them, they are discarded.

Maybe the solution is to define bundles by the extended attributes it
has, and any bundle-aware system MUST transform that bundle into a zip
bundle if it is copied/moved to a foreign filesystem that do not
support extended attributes.

> Another point from the spec:
> 
>   When a bundle must be copied or moved in a media that only accept
>   files and not folders, the bundle MUST be transformed into a ZIP
> bundle.
> 
> Why not do this for all directories, not just bundles?

Well, I'm just defining bundles now, nothing else. I think actually if
I try to send a folder as attachement, I would not be able to (my MUA
will complain). if the MUA is bundle-aware, it ZIP the bundle before
sending w/o showing me some error.

Mildred
-- 
Mildred Ki'lya
Site:	<http://mildred632.free.fr/>
XMPP:	<mildred at jabber.fr> (GoogleTalk, Jabber)

GPG:	197C A7E6 645B 4299 6D37 684B 6F9D A8D6 [9A7D 2E2B]