Re: Moving Deskbar's beagle handler to beagle itsself

Hash: SHA1

Joe Shaw schrieb:
> Hi,
> On 8/20/07, Sebastian P�erl <marduk k-d-w org> wrote:
>> You're right, it isn't guaranteed that each beagle user uses deskbar as
>> well, but he has at least the option. Because Deskbar is part of gnome
>> it should be installed by default in most distros. Therefore, I think it
>> makes more sense to ship the plugin with beagle because it's useless
>> without it.
> Is there a technical reason why shipping with Beagle is preferable?
> Ie, loss of performance if Beagle isn't running?
No there isn't or it's negligible.

>> How often you change/release the beagle-live handler is your decision,
>> of course. Obviously, you have better knownledge when something changes
>> in beagle that affects the deskbar handler. We on the other hand, come
>> to know the changes if someone files a bug report.
>> What we want to achieve is to decrease the amount of time we spend on
>> fixing bugs in handlers. I know that your time is rare, too, but that's
>> why I'm asking kindly.
> My general inclination is that it's better for the handler to stay in
> deskbar, for a couple of reasons:
> (1) The brutal honesty is that we don't want to be maintaining any
> more code than we have to.  We don't really have any deskbar
> expertise; we're already maintaining things like Firefox, Thunderbird,
> and Epiphany extensions, and not especially well.  (Although I am
> hoping that our awesome SoC students will stick around after the
> summer is over and help solve this.)  We also have to deal with all
> kinds of external programs and libraries, and that makes this a
> particularly challenging module to maintain.
I totally understand. That's the problem most open-source developers face.

> (2) Beagle is supposed to be providing APIs for external applications
> to use, and other software like Nautilus and Yelp use these APIs.  The
> *theory* is that it would be easier for deskbar folks to maintain the
> Beagle backend themselves (using a published API) rather than for us
> to learn the internals of deskbar.  If we're finding that the deskbar
> backend is rotting, then there are probably one of two sub-problems:
>   (a) We (Beagle) are doing a bad job of announcing decisions and
>   changes we are making.  I absolutely know that this is true; for
>   instance, today dBera made a checkin which pretty radically changes
>   the way snippets are dealt with on the client-side -- for the
>   better: no more dealing with HTML -- but it was unknown even to me.
>   We need to improve our communication with the community, and
>   especially to the consumers of our APIs.
You're right. If you change your API you have to inform your "customers"
early so that they can adapt to the changes. In our case CCing
deskbar-applet-list should do it.

>   (b) There isn't interest in maintaining the deskbar backend.  This
>   sucks, but is understandable.  For larger changes like we've made
>   recently, we should take the lead on fixing outside apps.  But I'm
>   not sure it's any more likely that the handler will get any more love
>   if it's included in Beagle.
It's not the interest that's missing. Beagle and its python bindings are
 great. As always it's the lack of time and manpower. Of course, it
doesn't make any sense to move the handler to beagle if it's conceivable
that it won't get more love there.

> In the end, you guys (the deskbar maintainers) will ultimately make
> the decision as to whether or not to continue including it in your
> package.  My feeling is that it's no better suited here than there.
It will be included at least in the 2.20 release cycle. It isn't perfect
but it should do it most of the time.

It seems to me that we're facing the same kind of problems: No time, to
little manpower and a lot features that want to get implemented.
Therefore, I suggest that the beagle-live handler stays in Deskbar and
you keep us updated about the changes that are happening within beagle.

- --
Sebastian P�erl
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


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