Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"

[prev] [thread] [next] [Date index for 2005/07/26]

From: John Siracusa
Subject: Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
Date: 01:15 on 26 Jul 2005
On 7/25/05 6:12 PM, Michael G Schwern wrote:
> I really don't know how real plugin architectures deal with this sort of
> problem [...]

Ideally, plug-ins have a single, well-defined interface.  For example,
imagine an image viewer that supports plug-ins for image formats.  The
plug-in API would say something like, "We feed you a file path, you return a
buffer full of 16-bit-per-component color values in ARGB format."

That's obviously simplified in terms of the details (i.e., there'd probably
be some negotiation of pixel formats and some means of incremental data
transfer) but the overall structure is representative.  All the plug-in
knows--all it has to know--are the rules of its little world, it's interface
with the "parent" application.

Even within this simple structure, there are some conflict resolution
chores.  The plug-ins would have to somehow register with the parent app,
indicating which image formats they can understand.  If two plug-ins both
claim to be able to read the same format, there has to be some set of rules
for choosing among them.  Or maybe this situation is simply reported as an
error.

Bookkeeping and conflict resolution are unavoidable in any plug-in
situation.  The idea is to lay out the rules beforehand, and make the parent
app responsible for enforcing them.  Then make the actual plug-in interface
as simple as possible.  This ensures that plug-in authors don't need to know
every intricacy of the entire app; they just need to know the API that
they're plugging into.  And they certainly don't need to know or care what
other plug-ins are doing.

Of course, a lot of plug-ins are not as simple as an the image format
parsers described above.  As the tasks assigned to plug-ins become more
complex, the inclination is to extend the plug-in API to handle the new
needs.  This may continue until a plug-in can do virtually "anything" within
the app.  Mozilla/Firefox "extensions" are an contemporary example of this.
They're also sometimes called "plug-ins," but "extensions" is the more
appropriate term.  They are powerful, but conflicts are common among
extensions that both try to extend the same thing (e.g., two mouse-gesture
extensions).

Web browsers also have an established "simple" (some would even say "brain
dead") plug-in interface for web content: the venerable "Netscape Plug-In
API" that lets you view movies and listen to audio and play flash inside web
pages.  Many more people have those kinds of plug-ins installed than run
Firefox-style "extensions."  In practice, it's very rare to see a conflict
among, say, the QuickTime and RealAudio web browser plug-ins.  They even
tend to play nice with MIME type and file name extension ownership within
the limited realm of the web browser plug-in ecosystem.

If your needs are too complex for a "simple" plug-in API, the best bet is to
design multiple smaller APIs instead of extending the plug-in interface to
encompass all possible functionality.  This may seem somewhat tangential to
the issue of how, exactly, the plug-in system is implemented, but it is
related.

If you use something like subclassing or multiple inheritance as your
"plug-in" mechanism, it's almost impossible to define and enforce a simple
API and set of plug-in rules (since, by their nature, subclasses can
override/augment "anything.")  And as Michael Schwern has been elaborating
on in recent posts, it also makes conflict resolution and cross-plug-in
interference and incompatibilities very, very difficult to manage and
predict, especially in the long term.

-John

(message missing)

Re: Annouce: DBIx::Class, a.k.a "taking the easy way out"
John Siracusa 01:15 on 26 Jul 2005

Delegation vs Hooks (was: Annouce: DBIx::Class, a.k.a "taking the easy way out")
=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= 23:27 on 26 Jul 2005

Generated at 16:37 on 28 Jul 2005 by mariachi v0.52