Revision 7ee8df0e627b2e4c71663f91590ba5284a41ff59

[Eric Polino]

On 6/14/07, Sean Egan <seanegan at gmail.com> wrote:
>
> 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.


Granted it doesn't change very often, but it does add the complexity to the
code.  Let's say some Pidgin devel notices there is a problem in the sound
system and fixes it.  They must then notify the Finch devels to go fix it in
the Finch sound system, and vis versa.  Or, the Pidgin and Finch devels must
forever remember to keep an eye on Finch and Pidgin, respectively, sound
changes that might prove useful for their side of things.  I just think that
duplicating code here adds a layer of complexity that isn't needed when a
solution isn't too difficult to implement.

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


I agree, and I'm not sure if a plugin is the best solution.  Though adding
sound as a plugin in Finch is different than adding it as a plugin for
Pidgin.  Adding it as a plugin for Finch is about users not having sound
scare the crap out of the roommate with random sounds when they remote in to
reconnect to their screen session and hop back onto Finch.


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.


To me this seems to introduce a potential lacking in the current
architecture of Pidgin.  I like how it's currently designed (
http://pidgin.im/~elb/images/pidgin-arch.png).  But it seems that there
should be another layer or module section that should/could be added.  This
layer would be part of the UI but not dependent to a specific UI.  Sound is
a perfect example of what would go there.  Sound isn't dependent on Finch or
Pidgin or any other client, but it's clearly, as Sean stated, a UI feature.
Can such a layer be added.  This way we don't have to add UI stuff to purple
to reduce duplication, but we can still consolidate UI code that isn't UI
specific.  As it stands all the UI code has to be either Pidgin or Finch, no
generic ground.

> 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.
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>



-- 
"...indexable arrays, which may be thought of as functions whose domains are
isomorphic to contiguous subsets of the integers."
--Haskell 98 Library Report
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20070614/d068122d/attachment.html>