[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mtos-dev
Subject:    Re: [MTOS-dev] [openmelody] Re:  config.yaml plugin sets
From:       Jay Allen <jay () endevver ! com>
Date:       2009-12-12 6:42:21
Message-ID: 444369190912112242wbd55462mf9ccfb5bc6734a0d () mail ! gmail ! com
[Download RAW message or body]

On Thu, Dec 10, 2009 at 11:12 AM, Chad Everett <2009@everitz.com> wrote:
> The "extends" key would require the existence of the "base" plugin (that
> being extended).
>
> To further the example, if I had an admin interface, it would extend
> MT-Notifier.  So if someone were to install the MT-Notifier Admin, it may
> work well enough to say "MT-Notifier not present - download?" (thus
> requiring some extra information to make this work).  But the plugin itself
> would not work.

Byrne and I were talking about this sort of thing one day.  There are
actually two different types of relationships at play here
differentiated mainly by how much one plugin depends on another:

    1) Plugins - One plugin provides a general framework that others
plug into to do some class of related features.  For example, if the
"text formatting" filters functionality (e.g. Convert Breaks,
Markdown, etc) was actually provided by a plugin instead of MT, all of
our text formatters would fit into this category

    2) Code Dependents - One plugin provides some small utility
methods that assist other plugins in providing their own set of
unrelated features.  Examples of these include ConfigAssistant and
Log4MT.

We don't really have many examples of either of these for a variety of
reasons, one of which is that there's no built-in way to formalize
this sort of relationship.  Basically the idea of a plugin framework
for plugins is a pretty daunting undertaking for no direct benefit.
Most developers are simply going to create multiple plugins which do
similar things because it's more expedient.

For the code dependents, it's usually documented as a requirement and
either included with the main plugin in the download or left to the
user to download separately.  And, if the plugin developer knows what
they're doing and codes defensively, the plugin would test for
existence of the other before using any of its functionality.  Of
course, that can be a major pain in the ass...

So I basically said to Byrne (and he agreed) that Melody needs to
formalize these two types of relationships somehow in order to save
developers significant amounts of time writing their own code to do
these sort of things or, if they don't, then saving users lots of
heartaches when things go wrong.  I envision a plugin being able to
assert a dependency on or plugin relationship with another via its
config.yaml in which case MT would hold onto it until all other
plugins were initialized.  If the main or utility providing plugin was
not present, MT would disable the asserting plugin so that its absence
would not cause problems.

> This key would naturally imply a relation.
>
> Meanwhile the "related" key would allow the plugin to function just fine
> even if the other plugin(s) weren't there - somewhat similar to SpamLookup
> (say I wanted "links" but not "lookups").

I question the value of this sort of grouping.  SpamLookup aside
(because I don't recall the specifics of the inter-relationship
between the three pieces), what end user benefit is there of grouping
plugins that have no shared code and can each run independently of
each other? Given that we only have two (that I know of: SpamLookup
and Markdown/Smartypants) "plugin set" distributions, developers
certainly haven't been able to find much reason to group things in
this way.

And frankly, I'm kind of glad because my worst fear was of a wave of
ego-fluffing developer creating their own personalized sets.  As in
the "Endevver" plugin set, the "Apperceptive" plugin set, the
"mt-hacks.com" plugin set, each taking up swaths of real estate on
your plugin listing screen like some measurement contest normally
attributed to males...

It's nothing more than a "brand dependency" and an anti-pattern I
think we should strenuously design *against*.

Jay Allen
Endevver Consulting
(415) 702-0045
_______________________________________________
MTOS-dev mailing list
MTOS-dev@sixapart.com
http://www.sixapart.com/mailman/listinfo/mtos-dev
[prev in list] [next in list] [prev in thread] [next in thread]