duplicity-talk
[Top][All Lists]
Advanced

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

Re: [Duplicity-talk] Re: dbus patch


From: Kenneth Loafman
Subject: Re: [Duplicity-talk] Re: dbus patch
Date: Thu, 06 Nov 2008 08:25:38 -0600
User-agent: Thunderbird 2.0.0.17 (X11/20080925)

Michael Terry wrote:
> Phew, there were a lot of responses to my latest email so I'll try to
> get them all here, rather than writing 10 more emails.
> 
> XML output alternative to dbus:  Possible.  Could be just as
> discoverable if it wrote files to /var/log/duplicity/pid/XXXX or
> something.  Still would have a bloat cost that is probably equivalent.
>  And I don't think XML is really the right format for this kind of
> thing.  It's more for structured data than notification of events or
> logging.

Rather than XML, I would go for the Python Logging module.  It supports
many log options, including user configuration and networking.  Log
messages for parsing could be standardized.

> Network-transparant duplicity:  This wasn't in my scope.  I don't know
> off hand if dbus really supports/plans-to-support that or not.

Not sure we need this at the moment.  Let's concentrate on functionality
and reliability first.

> Shell-scriptabliity of dbus:  It's good.  With dbus-monitor and
> dbus-send, you can do everything you should need to.

That could work for cron jobs as well.

> GLib dependency:  dbus requires glib.  But dbus (and thus glib) are
> only used if they are available.

Sounds like it would have minimal impact on code size if dbus was not
available for, or not used by, duplicity.

> duplicity helper wrapper:  I'm not sure how this would work.  The
> wrapper would need some communication from duplicity that is
> machine-readable, so we'd just be adding an extra layer of complexity.
>  Did I not understand this?

I think this level of complexity should be avoided.  If a decision needs
to be made interactively, then we need to re-think the way we handle
errors, and make that part of the duplicity code base.

I'm in favor of the dbus functionality as long as the primary goal of
duplicity is not diminished, that of being a solid backup package that
will run unattended via cron or similar.  If it happens to obtain a user
interface that does not in any way interfere with that goal, then we
have a winner.

...Ken


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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