[prev in list] [next in list] [prev in thread] [next in thread]
List: mtos-dev
Subject: Re: [MTOS-dev] config.yaml plugin sets
From: Chad Everett <2009 () everitz ! com>
Date: 2009-12-10 18:16:26
Message-ID: 1b5c3ec0912101016o2c50a088q722af03485665287 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
There are a couple of thoughts in this area that I can throw in.
- The most practical implementation of a plugin set most have seen is
probably SpamLookup. It is made up of several plugins that ostensibly could
be used separately if you don't use all of them. Though I don't really use
SpamLookup now, when I did, I really didn't use much. So being able to use
part of the set without the whole is definitely a big plus - otherwise it's
just forcing more cruft down throat of users (see earlier thread about
growing plugins).
- The advantage to me of a plugin set is really from an organizational
perspective. Let's say that I want to unbundle some functionality and offer
an "open source" (intentionally lower cased here) plugin component with a
"for pay" plugin component. If I was able to create a "plugin set", then
those two - or more - pieces could be represented together in some way in
the UI as being related, rather than being two (or more) separate and
unrelated plugins. It increases the ability of developers to use open
source and build on it by offering sellable modules that can be plugged into
these offerings. At least that's the idea. Don't know if it would work,
but it seems promising.
As an example: I have thought for a while of providing the administrative
module and other add-ons to MT-Notifier in such an arrangement. Many of
Mark's plugins are offered in a basic version for free, but for additional
functionality, you have to purchase a "Pro" version.
- Along these same lines comes the idea of putting a particular author's
content into a plugin "superset". One of the difficulties with upgrading is
trolling through extlib to make sure that you haven't missed Brad's content
that is sitting out there from an old plugin install. While it's easier to
just install it in the "lib" directory under the plugin, this means that the
other plugins (or MT/Melody itself) can't make use of it in any reasonable
way. Perhaps by creating a Brad Choate set, they could do this somehow -
and we can stop digging through extra directories looking for content that
needs to be moved during the ugprade (this is just a personal pet peeve, or
as Jay puts it, pain point), and perhaps isn't related). Maybe just a
plugin "extlib" or something would work for this instead.
Chad Everett
Everitz Consulting
On Thu, Dec 10, 2009 at 12:30 PM, Byrne Reese <byrne@majordojo.com> wrote:
> Ok folks, (cc'ing MTOS-dev)
>
> Last night Jay merged in my commit to allow for yaml driven plugin sets.
> However, before we are 100% committed to this course of action I thought we
> should raise some questions and issues with the community first.
>
> When I first raised this changeset on MTOS-dev, Brad Choate voiced concerns
> and said it was "a step backwards" but did not qualify that statement at
> all. So I am left to conjecture a little bit.
>
> Here are some challenges we have with "plugin sets" as I see them.
>
> The first and foremost in my mind is a UI issue. Why must we group them
> together in some logical form? And is that really the best user experience?
>
> Note: I don't think so, which is why I eliminated this distinction in
> Melody (at a UI level only).
>
> Next, are there implied dependencies in a plugin set? If you disable one,
> can the others in the set operate? This is at least unclear.
>
> On the other hand, what advantages do plugin sets provide?
>
> In my opinion, the only real advantage a plugin set has is a packaging one.
> One can easily bundle a bunch of plugins together in a single directory -
> which can ease installation for some.
>
> There is a strong case to be made for the simplicity of one plugin per
> plugin-directory. Even if it offers some constraints, so-be-it. In the long
> run, simplicity and consistency of form across all plugins is better than
> anything else.
>
> So do people have opinions to share on this matter? I would love to hear
> them!
>
[Attachment #5 (text/html)]
There are a couple of thoughts in this area that I can throw in.<br><br>- The most \
practical implementation of a plugin set most have seen is probably SpamLookup. It \
is made up of several plugins that ostensibly could be used separately if you \
don't use all of them. Though I don't really use SpamLookup now, when I \
did, I really didn't use much. So being able to use part of the set without the \
whole is definitely a big plus - otherwise it's just forcing more cruft down \
throat of users (see earlier thread about growing plugins).<br> <br>- The advantage \
to me of a plugin set is really from an organizational perspective. Let's say \
that I want to unbundle some functionality and offer an "open source" \
(intentionally lower cased here) plugin component with a "for pay" plugin \
component. If I was able to create a "plugin set", then those two - or \
more - pieces could be represented together in some way in the UI as being related, \
rather than being two (or more) separate and unrelated plugins. It increases the \
ability of developers to use open source and build on it by offering sellable modules \
that can be plugged into these offerings. At least that's the idea. Don't \
know if it would work, but it seems promising.<br> <br>As an example: I have thought \
for a while of providing the administrative module and other add-ons to MT-Notifier \
in such an arrangement. Many of Mark's plugins are offered in a basic version \
for free, but for additional functionality, you have to purchase a "Pro" \
version.<br> <br>- Along these same lines comes the idea of putting a particular \
author's content into a plugin "superset". One of the difficulties \
with upgrading is trolling through extlib to make sure that you haven't missed \
Brad's content that is sitting out there from an old plugin install. While \
it's easier to just install it in the "lib" directory under the plugin, \
this means that the other plugins (or MT/Melody itself) can't make use of it in \
any reasonable way. Perhaps by creating a Brad Choate set, they could do this \
somehow - and we can stop digging through extra directories looking for content that \
needs to be moved during the ugprade (this is just a personal pet peeve, or as Jay \
puts it, pain point), and perhaps isn't related). Maybe just a plugin \
"extlib" or something would work for this instead.<br> <br>Chad \
Everett<br>Everitz Consulting<br><br><br><div class="gmail_quote">On Thu, Dec 10, \
2009 at 12:30 PM, Byrne Reese <span dir="ltr"><<a \
href="mailto:byrne@majordojo.com">byrne@majordojo.com</a>></span> wrote:<br> \
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Ok folks, (cc'ing MTOS-dev)<br> \
<br> Last night Jay merged in my commit to allow for yaml driven plugin sets. \
However, before we are 100% committed to this course of action I thought we should \
raise some questions and issues with the community first.<br> <br>
When I first raised this changeset on MTOS-dev, Brad Choate voiced concerns and said \
it was "a step backwards" but did not qualify that statement at all. So I \
am left to conjecture a little bit.<br> <br>
Here are some challenges we have with "plugin sets" as I see them.<br>
<br>
The first and foremost in my mind is a UI issue. Why must we group them together in \
some logical form? And is that really the best user experience?<br> <br>
Note: I don't think so, which is why I eliminated this distinction in Melody (at \
a UI level only).<br> <br>
Next, are there implied dependencies in a plugin set? If you disable one, can the \
others in the set operate? This is at least unclear.<br> <br>
On the other hand, what advantages do plugin sets provide?<br>
<br>
In my opinion, the only real advantage a plugin set has is a packaging one. One can \
easily bundle a bunch of plugins together in a single directory - which can ease \
installation for some.<br> <br>
There is a strong case to be made for the simplicity of one plugin per \
plugin-directory. Even if it offers some constraints, so-be-it. In the long run, \
simplicity and consistency of form across all plugins is better than anything \
else.<br>
<br>
So do people have opinions to share on this matter? I would love to hear \
them!<br></blockquote></div><br>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic