Re: [Duplicity-talk] Re: dbus patch

[edgar . soldin]

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

I am worried dbus, glib would be needed to have structured output from 
duplicity. This would make it mandatory for ftplicity then, which also 
should run unattended from cron.

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

the current error & fail concept is convenient, if only the reason for 
the error would be delivered more elaboratly (errorcode, stderr).

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

Maybe interaction should be seen independent of the need of machine 
parsable output.

The first is actually needed by humans to influence a running duplicity 
or check it's state.
The second is important to automatically interpret the success of a 
duplicity action.

All I wish for is a cleaner error handling and messaging, even if my 
system or user can't deliver dbus and glib.

Thanks .. ede