[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Re: [rdiff-backup-users] Tar replacement - format p

From: Will Dyson
Subject: Re: [Duplicity-talk] Re: [rdiff-backup-users] Tar replacement - format proposal
Date: Fri, 26 Sep 2003 17:07:25 -0400

On Fri, 2003-09-26 at 09:16, John Goerzen wrote:

Originally sent this just to John, but intended it for the whole list.

> Moreover, you don't need XML for what you are trying to achieve.  All you
> need is something "more versatile than tar".  It shouldn't be hard to arrive
> at a key/value system.  For instance, for files, you could have:
>   NAME\0/foo/bar/baz\0
>   MTIME\0514341312\0
>   CTIME\03413413214\0
> Of course, you could write the MTIME and CTIME in binary, and you could
> abbreviate those names to "N", "M", and "C" to save time.  What's more, this
> format is quite extensible, almost to the same degree as XML, and you save
> space in the archive and space in memory and library requirements, not to
> mention ease processing.
> Null-terminated strings are easy for anyone to parse without having to load
> a separate library.  (You could also use Pascal-style "leading length byte"
> strings, which are also easy to parse.)

If we decide to echew XML, I would go with something like the record-jar
format described in The Art of Unix Programming

However, XML has the desirable property of being hierarchical. This is
nice when describing things like ACLs. Hierarchical structures can be
flattened into something like this

Name: /foo/bar/baz
AclEntry-read-permit-1: username
AclEntry-read-permit-2: otheruser
AclEntry-read-deny-1: someuser

But I think it is worth considering the hassle of this vs the hassle of
creating a stripped down or special purpose xml parser.

Will Dyson
"Back off man, I'm a scientist!" -Dr. Peter Venkman

reply via email to

[Prev in Thread] Current Thread [Next in Thread]