Moving Sound into Core

[Eric Polino]

Continuation of old thread: Revision
7ee8df0e627b2e4c71663f91590ba5284a41ff59

I have been brewing over what to do about duplicating code.  As Ethan
pointed out, another layer of abstraction is pointless and/or not needed.
Some have suggested to move sound into the core so that UI's that want sound
can hook into it, and those that don't can just ignore it.  I'm not sure
exactly how this would work as I am new to a lot of this, but it seems to
make sense to me at a superficial level.  I'm starting up this thread to get
a feel for what people think about moving sound into the core.

As it stands the sound that Finch has is pretty much a carbon copy of
gtksound with a few name changes here and there.

Evan: Sean mentioned about that it would be good to ask you...consider this
asking you.

Regards,
Eric



On 6/15/07, Ethan Blanton <elb at pidgin.im> wrote:
>
> Eric Polino spake unto us the following wisdom:
> > 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.
>
> What would you envision such a layer providing, that libpurple does
> not provide?  Would you envision it containing UI-specific code?  If
> so, then it is not "generic" and cannot be used across all UIs; if
> not, then why does it not fit squarely into "core plugin" ground?
> Just because a plugin links successfully against the core and does not
> require UI cooperation, does not mean it cannot provide something that
> we consider an "interface" feature.  This division is about code
> dependencies and architecture, not user-visible functionality.  In
> fact, I don't think the user can even tell whether a plugin is core or
> UI.
>
> I just don't see what adding an artificial layer would help with, and
> I don't see any requirement which would make the extra layer anything
> but artificial.
>
> Ethan
>
> --
> The laws that forbid the carrying of arms are laws [that have no remedy
> for evils].  They disarm only those who are neither inclined nor
> determined to commit crimes.
>                 -- Cesare Beccaria, "On Crimes and Punishments", 1764
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGcqKzr9kA9Ig8HBQRAjciAJ0RiE9HOr59/sFZ0+uSOf37xHLNDwCgxb96
> uqyAXh+Dl3rPZyFipN9h0bs=
> =/wTn
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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/20070615/9085f86b/attachment.html>