Re: [Duplicity-talk] On replacing tar, why not dar ?

[Aaron Whitehouse]

I haven't personally used dar. It looks as though it has some very interesting features, but mainly only one (quite active) developer. I see that public key encryption is only available in the pre-release version:
http://sourceforge.net/p/dar/feature-requests/67/

I'm always nervous when people talk about a complete rewrite, particularly in a small project and particularly where it is something critical like backups (and you may not find issues until you come to restore the backup many years later). It also reminds me of:
http://onstartups.com/tabid/3339/bid/2596/Why-You-Should-Almost-Never-Rewrite-Your-Software.aspx
http://www.joelonsoftware.com/articles/fog0000000069.html
It tends to create a pretty bad user experience: all the developers want to work on the new version; all the users are on the old version; and you spend all your time telling users that their bug will be fixed in the new version, but that they can't use that yet because it isn't finished.

Is there any reason that we couldn't do things more incrementally? Say:
1. add in dar to do exactly what we currently use tar for (and no more; potentially activated by a commandline option?);
2. switch the default to write dar files (but read either type);
3. as developers have time, we could replace pieces of home-brew code to use dar's features when duplicity is using dar files; and
4. if maintenance of the tar-writing codepaths is considered too much of a burden, turn off tar file output (though keep tar reading code).

I would expect it would create a much better user experience, if nothing else, and would mean that we could more gracefully deal with things like the user having an old version of libdar that doesn't contain the required feature (taking the above example, use our encryption code for public key encryption until the user is both outputting to dar files *and* has a version of libdar that supports public key encryption).

Just my thoughts and happy to be proven wrong by somebody who knows more!

Aaron

On 08/09/15 16:54, Kenneth Loafman wrote:

Except for rsync processing, dar does a lot of what we need: compression, encryption, hard links, split files, etc., plus it's fast.  The backend processing could be done after the .dar file creation, so it looks like rsync processing is the only addition to be made.  Granted, handling the signature files would be a PITA, but that could be done by dar as well.  We would only need two file types, dar and sig.

This would do away with most of duplicity's guts and make libdar the central player in duplicity.

This does not sound like a bad idea to me.  Someone else weigh in please.

...Ken

On Mon, Sep 7, 2015 at 10:00 AM, Kenneth Loafman <address@hidden> wrote:

Don't really need to reimplement, just make sure that the python bindings are sufficient to access libdar fully.  I think that driving dar from duplicity would be nearly a rewrite since I see so much that dar does would replace much of duplicity's functionality.  It might even be easier to start with libdar and add the librsync functionality to it, wrapping all that with multiple backends.  Just a wild thought, but it would give us a solid basis on which to add.

A new structure like dar would solve a lot of the problems we currently have, including split signature files, better manifest handling, etc.

Just a thought, but sometimes a complete rewrite solves a lot of problems.

On Wed, Sep 2, 2015 at 9:30 PM, Meta Schima <address@hidden> wrote:

People have made some python bindings to dar, but re-implementing dar in python is probably not feasible.

> -----Original Message-----
> From: address@hidden
> Sent: Mon, 31 Aug 2015 11:35:12 +0200
> To: address@hidden
> Subject: Re: [Duplicity-talk] On replacing tar, why not dar ?
>
> On 31.08.2015 02:50, Meta Schima wrote:
>> Hello,
>>
>>     In regards to:
>>
>> http://duplicity.nongnu.org/new_format.html
>>
>>     Why not use the dar archive ? It was specifically designed to
>> replace tar, and adds all the features that you want:
>>
>> https://en.wikipedia.org/wiki/Dar_%28disk_archiver%29
>> http://dar.linux.free.fr/
>>
>>     It has also been in development for 10 years so is mature.
>>
>>     Just a suggestion.
>>
>
> tar is available as plain python module. are you aware of a python dar
> implementation?
>
> ..ede/duply.net
>
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk

____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk