Re: [Duplicity-talk] Re: dbus patch

[Michael Terry]

On Tue, Nov 4, 2008 at 1:35 PM, Dan Muresan <address@hidden> wrote:
> Stepping back a bit, what would glib integration bring? Duplicity
> doesn't seem like a very interactive type of application -- it seems
> similar to ssh / scp / ssh-askpass, for example.
>
> If we're talking merely about pausing / aborting operation based on
> front-end requests, wouldn't SIGSTOP / SIGINT, or perhaps a very simple
> "control socket" mechanism, do?

Yeah, for that one thing SIGSTOP would be fine.  I actually
experimented with this on the current code base and it seemed to work
for Amazon and local files.  When I asked this mailing list whether
that was normal or expected, no one responded.

And I agree we should step back a bit.  My position is still just
focused on getting dbus in as an optional dependency for its signal
handling.  I was just looking into the future and suggesting that if
we ever wanted two-way interaction, we'd need glib integration.

The only example of such two-way integration that I can think of now
is pausing/continuing.  duplicity as a command line tool already
immitates a 'method I call on a fictatious virtual duplicity daemon'.
So glib integration is not high on my list of wants, but it could be
at some point.

This is worth pointing out again -- dbus is still optional and
supposedly always will be (particularly since there's been no movement
on my patch).  The glib stuff was just theoretical.


As for Edgar's point, sure there are other interprocess communication
methods, but not all of them are as easy to write for or extensible as
dbus.  Much like picking Python for duplicity (presumably because it
made writing it much easier) despite its resource consumption/speed, I
prefer to write to dbus for its developer-friendliness.  Since I'm the
one that currently is doing this work, my vote in this regard has some
weight.

As a frontend writer, I'd be happy to integrate with duplicity with
whatever its maintainers decide.  But I wouldn't personally be very
excited about reinventing some protocol over named pipes.

(Besides the above, DBus does have technical merits to recommend it --
easier for multiple processes to watch the same duplicity, type
checking, cross platform, etc.)

-mt