Re: [rdiff-backup-users] Tar replacement - format proposal

[Kevin Spicer]

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

> One problem I see is XML.  Yes, it is versatile, but it is also overkill for
> this and it is complex.  An archive should be as simple as possible, and it
> should be able to be restored with as few tools as possible.  XML is not
> simple, and using it will generally require a libxml on the system.  This
> can right away put your format out of the running for things like
> installers, critical system backups, and anything else that is extremely
> space-conscious for program footprint and required shared libraries.
> 
> 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.
> 

I agree thats a good idea, I suggested using xml for everything earlier
- but with reflection thats perhaps not such a great idea because of the
bloat factor.  Another important consideration is that the necessary
tools to extract an archive should be as compact and self reliant as
possible as they are the kind of tools you need on rescue floppies and
the like.  Needing xml is probably unwanted bloat.

> 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.)





BMRB International 
http://www.bmrb.co.uk
+44 (0)20 8566 5000
_________________________________________________________________
This message (and any attachment) is intended only for the 
recipient and may contain confidential and/or privileged 
material.  If you have received this in error, please contact the 
sender and delete this message immediately.  Disclosure, copying 
or other action taken in respect of this email or in 
reliance on it is prohibited.  BMRB International Limited 
accepts no liability in relation to any personal emails, or 
content of any email which does not directly relate to our 
business.