Re: [Duplicity-talk] Re: dbus patch

[Edgar Soldin]

well,

currently duplicity is small and only depending on packages that are
necessary for the job to be done. Dbus is not one of them.

3MB is lots in a embbedded device environment, eg. just checked my WRT54
router w/ linux on it.. it has 2MB where at least 1MB is already filled
.. but currently it could theoretically drive duplicity as librsync,
python, gnupg packages are available - this won't be the case with dbus
as dependency

I don't see why to make a desktop component mandatory for a application
that might be used only from shell interfaces by some.

I'd suggest to go back one step and reconsider other established ways
of  interprocess communication. Wouldn't sockets, signals, named pipes
(you name them) do the trick as well? One can still write a dbus
translator for these interfaces, if necessary. Plus these interface
could be used by commandline based wrappers, like bash ftplicity ;)

just my 2cents.. ede
-- 

> On Sun, Nov 2, 2008 at 4:29 PM, Dan Muresan <address@hidden> wrote:
>   
>> OK, I suppose I wasn't very clear; my concern was the number of
>> dependencies / ease of installation -- not performance.
>>     
>
> That makes more sense.  I don't know why I assumed performance.
>
> A quick reminder to followers of the conversation -- we're talking
> about a possible future change of integrating the glib main loop into
> duplicity as a non-optional dependency and the resource drain that
> would incur.
>
> So, since I didn't actually have any information about RAM/disk usage
> of glib, I tried to get some.  This is all on my Ubuntu Intrepid
> laptop.
>
> On-disk space:
>   python-gobject: 1088
>   libglib2.0-0: 1768
>
> So the addition of glib is ~3M disk.  That's not bad, all told.  And
> most people already have the packages.
>
> So what about RAM?  I got the following stats by forcing a sleep right
> after initialization (before even command line parsing) and checking
> top.
>
> No dbus (baseline):
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>   8249 mike      20   0  9064 6280 2500 S    0  0.2   0:00.10 duplicity-bin
>
> With just gobject:
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>   14357 mike      20   0 11048 7364 3036 S    0  0.2   0:00.18 duplicity-bin
>
>   Increase in VIRT from baseline: 1984
>   Increase in RES from baseline:  1084
>   Increase in SHR from baseline:   536
>
> With gobject + dbus:
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>   8295 mike      20   0 12336 8456 3476 S    0  0.2   0:00.16 duplicity-bin
>
>   Increase in VIRT from baseline: 3272
>   Increase in RES from baseline:  2176
>   Increase in SHR from baseline:   976
>
>
> So the case under discussion (adding just gobject) raised VIRT by 2M,
> RES by 1M and SHR by 0.5M.  I never seem to get this right, but I
> believe the relevant number there is RES?  The space that duplicity is
> actually consuming in real memory.
>
> From my perspective (targetting desktop users), 1M isn't bad, but Dan,
> you're coming at this from a tiny server perspective.  Would 1M break
> the duplicity bank?
>
>
> Also, Ken as maintainer, I'd like some feedback on the whole strategic
> vision of dbus, glib integration, and/or my patch.
>
> (Ken, you mentioned a move to sourceforge?  Should we not start
> claiming the dbus name 'org.nongnu.duplicity' then?  :)  I'd also give
> a shoutout to launchpad if you're shopping around for project hosts --
> I was never very thrilled with SF.)
>
> -mt
>
>
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/duplicity-talk
>