elb at pidgin.im
Fri Jun 15 10:31:15 EDT 2007
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
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the Devel