Revision 7ee8df0e627b2e4c71663f91590ba5284a41ff59

[Sean Egan]

 On 6/13/07, Sadrul Habib Chowdhury <imadil at gmail.com> wrote:
> The reason I like the idea of a plugin better is mostly to reduce the
> code duplication, and always not having to update both pidgin/ and
> finch/ if some sound-related bug is being fixed. The same also goes for
> autoreconnecting stuff, for which I considered bringing back the old
> auto-reconnect plugin. Duplicating same/similar code burdens us with
> extra maintenance, which can be rather annoying.

This is true, but the marginal cost of maintaining the code twice is
mostly negligible when you look at the revision history of the sound
code. It doesn't change very often.

You could make the code duplication argument about a lot of things,
but that doesn't necessarily mean they should all be plugins. We don't
want to wind up like Miranda, where you need to load 20 plugins before
you can do anything useful. ;)

Finch and Pidgin duplicate a lot of code because they're developed by
the same developers, running the same operating systems, preferring
the same behaviors. If there's anything that's currently in UI code
(and sound is definitely a UI feature), that you're considering adding
to libpurple, you should ask Evan first. He probably doesn't want it.
He doesn't want our sound code, and he doesn't want our
auto-reconnect.

> Can we introduce the gstreamer
> dependency in libpurple in 2.x.y, or will that have to be postponed for
> 3?

gstreamer (and -vv) can be added to the 2.0 series.

> You probably mean the gntgf and gntclipboard plugins, which do
> communicate with the X server. Other plugins should be able to do
> similar things. And I think some dbus script [1] that do neat stuff for
> pidgin should work as nicely for finch too (given that there's only
> one purple-client running at a time).

A Finch docklet plugin would be rad.

-s.