You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Allen Gilliland <al...@sun.com> on 2006/08/29 18:59:49 UTC
cleanup weblog entries plugins
i'd like to do a few things with the weblog entries plugins which are
maintained in the "contrib/plugins" directory right now.
1. Evaluate and vote on which plugins should be shipped with Roller and
which should be added on separately.
2. Move all plugins which are shipped with Roller into the core src
directory so they are actually part of the main build.
3. Remove all plugins which are *not* going to be shipped with Roller
from being included in a standard build. They can stay in the contrib
area and just be built separately, or possibly moved elsewhere like the
Roller support project.
anyone object to any of these steps?
if not then lets start with #1 now and get some opinions on what plugins
should be shipped with Roller. personally, i don't really care that
much about which of the existing plugins go into the core build, but i
think that ideally we would keep it to a minimal set since the nature of
a plugin is to be added on. this is my take ...
keep in core:
ConvertLineBreaksPlugin
BookmarkPlugin
ObfuscateEmailPlugin
make optional:
TopicTagPlugin
WikipediaLinkPlugin
GoogleLinkPlugin
TextilePlugin
AcronymsPlugin
SmileysPlugin
-- Allen
Re: cleanup weblog entries plugins
Posted by Matt Raible <mr...@gmail.com>.
On 8/29/06, Elias Torres <el...@torrez.us> wrote:
> +1
>
> Allen Gilliland wrote:
> > i'd like to do a few things with the weblog entries plugins which are
> > maintained in the "contrib/plugins" directory right now.
> >
> > 1. Evaluate and vote on which plugins should be shipped with Roller and
> > which should be added on separately.
> >
> > 2. Move all plugins which are shipped with Roller into the core src
> > directory so they are actually part of the main build.
> >
> > 3. Remove all plugins which are *not* going to be shipped with Roller
> > from being included in a standard build. They can stay in the contrib
> > area and just be built separately, or possibly moved elsewhere like the
> > Roller support project.
> >
> > anyone object to any of these steps?
> >
> > if not then lets start with #1 now and get some opinions on what plugins
> > should be shipped with Roller. personally, i don't really care that
> > much about which of the existing plugins go into the core build, but i
> > think that ideally we would keep it to a minimal set since the nature of
> > a plugin is to be added on. this is my take ...
> >
> > keep in core:
> > ConvertLineBreaksPlugin
> > BookmarkPlugin
> > ObfuscateEmailPlugin
> >
> > make optional:
> > TopicTagPlugin
> > WikipediaLinkPlugin
> > GoogleLinkPlugin
> > TextilePlugin
> > AcronymsPlugin
> > SmileysPlugin
I'd like to see SmileysPlugin kept in core, why make it optional?
Matt
> >
> > -- Allen
> >
>
Re: cleanup weblog entries plugins
Posted by Elias Torres <el...@torrez.us>.
+1
Allen Gilliland wrote:
> i'd like to do a few things with the weblog entries plugins which are
> maintained in the "contrib/plugins" directory right now.
>
> 1. Evaluate and vote on which plugins should be shipped with Roller and
> which should be added on separately.
>
> 2. Move all plugins which are shipped with Roller into the core src
> directory so they are actually part of the main build.
>
> 3. Remove all plugins which are *not* going to be shipped with Roller
> from being included in a standard build. They can stay in the contrib
> area and just be built separately, or possibly moved elsewhere like the
> Roller support project.
>
> anyone object to any of these steps?
>
> if not then lets start with #1 now and get some opinions on what plugins
> should be shipped with Roller. personally, i don't really care that
> much about which of the existing plugins go into the core build, but i
> think that ideally we would keep it to a minimal set since the nature of
> a plugin is to be added on. this is my take ...
>
> keep in core:
> ConvertLineBreaksPlugin
> BookmarkPlugin
> ObfuscateEmailPlugin
>
> make optional:
> TopicTagPlugin
> WikipediaLinkPlugin
> GoogleLinkPlugin
> TextilePlugin
> AcronymsPlugin
> SmileysPlugin
>
> -- Allen
>
Re: cleanup weblog entries plugins
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Allen,
On Sep 4, 2006, at 4:28 PM, Allen Gilliland wrote:
> Craig L Russell wrote:
>> Hi Allen,
>> On Sep 1, 2006, at 9:14 AM, Allen Gilliland wrote:
>>> for the current set of plugins I think that's fine, we can just
>>> move all the current plugins in to the core src tree and then
>>> modify the config to only enable a subset of them. i'll go ahead
>>> and take this approach since it really is the easiest in our
>>> current situation.
>> It sounds like you've chosen the right approach.
>>>
>>> the main reason i proposed this though is that i believe very
>>> strongly that moving forward it's not our job to maintain all the
>>> plugins directly in the src tree. we don't have many people who
>>> do this right now, but eventually we want to build a user
>>> community that really does create and share plugins and that has
>>> to happen outside of the core project. we already have 10
>>> plugins, what happens if the list grows to 20, 50, etc?
>> I'd like to understand your concern better. Simply developing a
>> plugin doesn't require core knowledge of Roller, just the
>> interfaces exposed by the callbacks. If someone wants to develop a
>> plugin, under the current regime, a committer would have to test
>> and commit the plugin to the src tree. So do we *not* want "plugin
>> developers" to eventually become part of the committer list for
>> Roller?
>
> My concern may be a little premature, but the potential problem I
> see is that if all the plugins are part of the core build then we
> are 1) bloating the core application with code that may never be used
good point
> and 2) since plugins are not part of core functionality it is much
> easier for people to neglect them over time and not maintain them
good point
> and thus 3) the core developers feel obligated to maintain the
> plugin code which makes things harder on us.
I understand.
>
> I don't really care if we allow people to develop plugins directly
> in the core project, but I don't see why we would want *all*
> plugins to be built and packaged with the core build. That defeats
> the purpose of a plugin.
It seems that there might be a "core" set of plugins that make sense
to develop in the core, but I understand the issues with the other
plugins. Especially since over time, the plugin interface that we
expose will likely change, and obsolete plugins will have to be fixed
before we evolve the interface.
>
>
>>>
>>> as long as we make it easy for people to add in a plugin then i
>>> think it's best that they be developed and maintained outside of
>>> the core src.
>> If this is the case, perhaps it makes sense to create a new
>> project just for plugins. But this might be construed as anti-
>> community-building ("core developers" versus "plugin developers").
>> Personally, I think that building the community is a good thing,
>> and a developer starting out developing plugins is a good thing.
>> Once the number of quality contributions of plugins and patches by
>> a contributor is significant, the contributor should be considered
>> for committer status even though they don't work in the core. Just
>> my two cents.
>
> We have started a roller_support project at java.net specifically
> for this
seems like a good idea especially if it is well advertised.
Craig
> so that users who are only interested in themes, plugins, and
> custom editors can easily work on those things and download them
> separately.
>
> I agree that we want to build community, but in my opinion pushing
> these addons out of the core application does just that. It places
> the responsibility in the hands of the community instead of leaving
> it like it is now, where us core developers are the only ones
> really working on the them.
>
> -- Allen
>
>
>> Craig
>>>
>>> -- Allen
>>>
>>>
>>> Sean Gilligan wrote:
>>>> Anil Gangolli wrote:
>>>>>
>>>>> Sorry for entering this conversation a bit late.
>>>>>
>>>>> How about shipping these plugins but not enabling them by
>>>>> default. For example, I'd rather they ship as part of the
>>>>> normal install but we just comment them out in roller.properties.
>>>> Or we could have an admin page to enable them like for editor
>>>> pages.
>>>> -- Sean
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: cleanup weblog entries plugins
Posted by Allen Gilliland <Al...@Sun.COM>.
Craig L Russell wrote:
> Hi Allen,
>
> On Sep 1, 2006, at 9:14 AM, Allen Gilliland wrote:
>
>> for the current set of plugins I think that's fine, we can just move
>> all the current plugins in to the core src tree and then modify the
>> config to only enable a subset of them. i'll go ahead and take this
>> approach since it really is the easiest in our current situation.
>
> It sounds like you've chosen the right approach.
>>
>> the main reason i proposed this though is that i believe very strongly
>> that moving forward it's not our job to maintain all the plugins
>> directly in the src tree. we don't have many people who do this right
>> now, but eventually we want to build a user community that really does
>> create and share plugins and that has to happen outside of the core
>> project. we already have 10 plugins, what happens if the list grows
>> to 20, 50, etc?
>
> I'd like to understand your concern better. Simply developing a plugin
> doesn't require core knowledge of Roller, just the interfaces exposed by
> the callbacks. If someone wants to develop a plugin, under the current
> regime, a committer would have to test and commit the plugin to the src
> tree. So do we *not* want "plugin developers" to eventually become part
> of the committer list for Roller?
My concern may be a little premature, but the potential problem I see is
that if all the plugins are part of the core build then we are 1)
bloating the core application with code that may never be used and 2)
since plugins are not part of core functionality it is much easier for
people to neglect them over time and not maintain them and thus 3) the
core developers feel obligated to maintain the plugin code which makes
things harder on us.
I don't really care if we allow people to develop plugins directly in
the core project, but I don't see why we would want *all* plugins to be
built and packaged with the core build. That defeats the purpose of a
plugin.
>>
>> as long as we make it easy for people to add in a plugin then i think
>> it's best that they be developed and maintained outside of the core src.
>
> If this is the case, perhaps it makes sense to create a new project just
> for plugins. But this might be construed as anti-community-building
> ("core developers" versus "plugin developers").
>
> Personally, I think that building the community is a good thing, and a
> developer starting out developing plugins is a good thing. Once the
> number of quality contributions of plugins and patches by a contributor
> is significant, the contributor should be considered for committer
> status even though they don't work in the core. Just my two cents.
We have started a roller_support project at java.net specifically for
this so that users who are only interested in themes, plugins, and
custom editors can easily work on those things and download them separately.
I agree that we want to build community, but in my opinion pushing these
addons out of the core application does just that. It places the
responsibility in the hands of the community instead of leaving it like
it is now, where us core developers are the only ones really working on
the them.
-- Allen
>
> Craig
>
>>
>> -- Allen
>>
>>
>> Sean Gilligan wrote:
>>> Anil Gangolli wrote:
>>>>
>>>> Sorry for entering this conversation a bit late.
>>>>
>>>> How about shipping these plugins but not enabling them by default.
>>>> For example, I'd rather they ship as part of the normal install but
>>>> we just comment them out in roller.properties.
>>> Or we could have an admin page to enable them like for editor pages.
>>> -- Sean
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: cleanup weblog entries plugins
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Allen,
On Sep 1, 2006, at 9:14 AM, Allen Gilliland wrote:
> for the current set of plugins I think that's fine, we can just
> move all the current plugins in to the core src tree and then
> modify the config to only enable a subset of them. i'll go ahead
> and take this approach since it really is the easiest in our
> current situation.
It sounds like you've chosen the right approach.
>
> the main reason i proposed this though is that i believe very
> strongly that moving forward it's not our job to maintain all the
> plugins directly in the src tree. we don't have many people who do
> this right now, but eventually we want to build a user community
> that really does create and share plugins and that has to happen
> outside of the core project. we already have 10 plugins, what
> happens if the list grows to 20, 50, etc?
I'd like to understand your concern better. Simply developing a
plugin doesn't require core knowledge of Roller, just the interfaces
exposed by the callbacks. If someone wants to develop a plugin, under
the current regime, a committer would have to test and commit the
plugin to the src tree. So do we *not* want "plugin developers" to
eventually become part of the committer list for Roller?
>
> as long as we make it easy for people to add in a plugin then i
> think it's best that they be developed and maintained outside of
> the core src.
If this is the case, perhaps it makes sense to create a new project
just for plugins. But this might be construed as anti-community-
building ("core developers" versus "plugin developers").
Personally, I think that building the community is a good thing, and
a developer starting out developing plugins is a good thing. Once the
number of quality contributions of plugins and patches by a
contributor is significant, the contributor should be considered for
committer status even though they don't work in the core. Just my two
cents.
Craig
>
> -- Allen
>
>
> Sean Gilligan wrote:
>> Anil Gangolli wrote:
>>>
>>> Sorry for entering this conversation a bit late.
>>>
>>> How about shipping these plugins but not enabling them by
>>> default. For example, I'd rather they ship as part of the normal
>>> install but we just comment them out in roller.properties.
>> Or we could have an admin page to enable them like for editor pages.
>> -- Sean
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: cleanup weblog entries plugins
Posted by Allen Gilliland <al...@sun.com>.
Thats a good point. Given that in the current model it's expected that
the plugin is initialized each time its used we may not be able to
follow the init once strategy. It would be nice if we can work towards
that though.
In any case, the bigger issue is if we can remove access to the
rendering model in plugins. I still think that's important and
something we should do for 3.0.
-- Allen
Anil Gangolli wrote:
>
> I remember running into essentially this problem before.
>
> Plugins like bookmark plugin could be initialized per website, but do
> need access to site-specific (bookmark) data. The topictag plugin can
> refer to bookmarks as well, but I think most people run with this
> disabled because it is not efficient.
>
> The instantiation and initialization model are coupled, since one
> expects that the plugin may store instance data/references at
> initialization time, and use it when called subsequently to process the
> entry. If the call to process the entry could pass in enough contextual
> information to relieve the plugin from keeping this state, it would
> allow sharing instances of the plugins and initialize them only once.
> In other words, init should pass in server-wide configuration
> information, and the call to process the entry should pass in all
> contextual references necessary.
>
> --a.
>
>
> ----- Original Message ----- From: "Allen Gilliland"
> <al...@sun.com>
> To: <ro...@incubator.apache.org>
> Sent: Friday, September 01, 2006 11:14 AM
> Subject: Re: cleanup weblog entries plugins
>
>
>> okay, this has been committed to the 3.0 branch.
>>
>> there is one more important little change that i would like to propose
>> with regards to the entry plugins. the entry plugin architecture was
>> cleaned up quite a bit for 3.0, but one thing was left which i would
>> like to address. the current entry plugin interface has this method ...
>>
>> public void init(WebsiteData weblog, Map model) throws RollerException;
>>
>> ... which initializes the plugin for the given weblog. i would like
>> to change this method signature to not pass in the model Map to
>> plugins for a few reasons ...
>>
>> 1. security. giving a plugin access to the model is potentially
>> dangerous because a plugin could then remove/modify existing items in
>> the model or add potentially harmful or inappropriate items to the
>> model. we have specifically designed the rendering model architecture
>> to accomplish this task. Model objects are what should be added to
>> the rendering model, not random items via entry plugins.
>>
>> 2. simplicity. i don't think plugins need the model to do their job.
>> they are currently only meant to take the entry content and transform
>> it in some way and that shouldn't require access to the model.
>>
>> 3. performance. technically if a plugin doesn't need to be
>> initialized each time with model data relevant to a given request then
>> it would be possible to initialize the plugins only once and then
>> reuse them.
>>
>> also note, right now the only plugin that even makes use of the model
>> that is passed in at init time is the Textile plugin, which i have not
>> included in the core src tree as a supported plugin mainly because it
>> requires an additional library and i think those kinds of plugins
>> really should be added on externally.
>>
>> what do others think?
>>
>> -- Allen
>>
>>
>> Allen Gilliland wrote:
>>> for the current set of plugins I think that's fine, we can just move
>>> all the current plugins in to the core src tree and then modify the
>>> config to only enable a subset of them. i'll go ahead and take this
>>> approach since it really is the easiest in our current situation.
>>>
>>> the main reason i proposed this though is that i believe very
>>> strongly that moving forward it's not our job to maintain all the
>>> plugins directly in the src tree. we don't have many people who do
>>> this right now, but eventually we want to build a user community that
>>> really does create and share plugins and that has to happen outside
>>> of the core project. we already have 10 plugins, what happens if the
>>> list grows to 20, 50, etc?
>>>
>>> as long as we make it easy for people to add in a plugin then i think
>>> it's best that they be developed and maintained outside of the core src.
>>>
>>> -- Allen
>>>
>>>
>>> Sean Gilligan wrote:
>>>> Anil Gangolli wrote:
>>>>>
>>>>> Sorry for entering this conversation a bit late.
>>>>>
>>>>> How about shipping these plugins but not enabling them by default.
>>>>> For example, I'd rather they ship as part of the normal install but
>>>>> we just comment them out in roller.properties.
>>>>
>>>> Or we could have an admin page to enable them like for editor pages.
>>>>
>>>> -- Sean
>>
>
Re: cleanup weblog entries plugins
Posted by Anil Gangolli <an...@busybuddha.org>.
I remember running into essentially this problem before.
Plugins like bookmark plugin could be initialized per website, but do need
access to site-specific (bookmark) data. The topictag plugin can refer to
bookmarks as well, but I think most people run with this disabled because it
is not efficient.
The instantiation and initialization model are coupled, since one expects
that the plugin may store instance data/references at initialization time,
and use it when called subsequently to process the entry. If the call to
process the entry could pass in enough contextual information to relieve the
plugin from keeping this state, it would allow sharing instances of the
plugins and initialize them only once. In other words, init should pass in
server-wide configuration information, and the call to process the entry
should pass in all contextual references necessary.
--a.
----- Original Message -----
From: "Allen Gilliland" <al...@sun.com>
To: <ro...@incubator.apache.org>
Sent: Friday, September 01, 2006 11:14 AM
Subject: Re: cleanup weblog entries plugins
> okay, this has been committed to the 3.0 branch.
>
> there is one more important little change that i would like to propose
> with regards to the entry plugins. the entry plugin architecture was
> cleaned up quite a bit for 3.0, but one thing was left which i would like
> to address. the current entry plugin interface has this method ...
>
> public void init(WebsiteData weblog, Map model) throws RollerException;
>
> ... which initializes the plugin for the given weblog. i would like to
> change this method signature to not pass in the model Map to plugins for a
> few reasons ...
>
> 1. security. giving a plugin access to the model is potentially dangerous
> because a plugin could then remove/modify existing items in the model or
> add potentially harmful or inappropriate items to the model. we have
> specifically designed the rendering model architecture to accomplish this
> task. Model objects are what should be added to the rendering model, not
> random items via entry plugins.
>
> 2. simplicity. i don't think plugins need the model to do their job. they
> are currently only meant to take the entry content and transform it in
> some way and that shouldn't require access to the model.
>
> 3. performance. technically if a plugin doesn't need to be initialized
> each time with model data relevant to a given request then it would be
> possible to initialize the plugins only once and then reuse them.
>
> also note, right now the only plugin that even makes use of the model that
> is passed in at init time is the Textile plugin, which i have not included
> in the core src tree as a supported plugin mainly because it requires an
> additional library and i think those kinds of plugins really should be
> added on externally.
>
> what do others think?
>
> -- Allen
>
>
> Allen Gilliland wrote:
>> for the current set of plugins I think that's fine, we can just move all
>> the current plugins in to the core src tree and then modify the config to
>> only enable a subset of them. i'll go ahead and take this approach since
>> it really is the easiest in our current situation.
>>
>> the main reason i proposed this though is that i believe very strongly
>> that moving forward it's not our job to maintain all the plugins directly
>> in the src tree. we don't have many people who do this right now, but
>> eventually we want to build a user community that really does create and
>> share plugins and that has to happen outside of the core project. we
>> already have 10 plugins, what happens if the list grows to 20, 50, etc?
>>
>> as long as we make it easy for people to add in a plugin then i think
>> it's best that they be developed and maintained outside of the core src.
>>
>> -- Allen
>>
>>
>> Sean Gilligan wrote:
>>> Anil Gangolli wrote:
>>>>
>>>> Sorry for entering this conversation a bit late.
>>>>
>>>> How about shipping these plugins but not enabling them by default. For
>>>> example, I'd rather they ship as part of the normal install but we just
>>>> comment them out in roller.properties.
>>>
>>> Or we could have an admin page to enable them like for editor pages.
>>>
>>> -- Sean
>
Re: cleanup weblog entries plugins
Posted by Allen Gilliland <al...@sun.com>.
okay, this has been committed to the 3.0 branch.
there is one more important little change that i would like to propose
with regards to the entry plugins. the entry plugin architecture was
cleaned up quite a bit for 3.0, but one thing was left which i would
like to address. the current entry plugin interface has this method ...
public void init(WebsiteData weblog, Map model) throws RollerException;
... which initializes the plugin for the given weblog. i would like to
change this method signature to not pass in the model Map to plugins for
a few reasons ...
1. security. giving a plugin access to the model is potentially
dangerous because a plugin could then remove/modify existing items in
the model or add potentially harmful or inappropriate items to the
model. we have specifically designed the rendering model architecture
to accomplish this task. Model objects are what should be added to the
rendering model, not random items via entry plugins.
2. simplicity. i don't think plugins need the model to do their job.
they are currently only meant to take the entry content and transform it
in some way and that shouldn't require access to the model.
3. performance. technically if a plugin doesn't need to be initialized
each time with model data relevant to a given request then it would be
possible to initialize the plugins only once and then reuse them.
also note, right now the only plugin that even makes use of the model
that is passed in at init time is the Textile plugin, which i have not
included in the core src tree as a supported plugin mainly because it
requires an additional library and i think those kinds of plugins really
should be added on externally.
what do others think?
-- Allen
Allen Gilliland wrote:
> for the current set of plugins I think that's fine, we can just move all
> the current plugins in to the core src tree and then modify the config
> to only enable a subset of them. i'll go ahead and take this approach
> since it really is the easiest in our current situation.
>
> the main reason i proposed this though is that i believe very strongly
> that moving forward it's not our job to maintain all the plugins
> directly in the src tree. we don't have many people who do this right
> now, but eventually we want to build a user community that really does
> create and share plugins and that has to happen outside of the core
> project. we already have 10 plugins, what happens if the list grows to
> 20, 50, etc?
>
> as long as we make it easy for people to add in a plugin then i think
> it's best that they be developed and maintained outside of the core src.
>
> -- Allen
>
>
> Sean Gilligan wrote:
>> Anil Gangolli wrote:
>>>
>>> Sorry for entering this conversation a bit late.
>>>
>>> How about shipping these plugins but not enabling them by default.
>>> For example, I'd rather they ship as part of the normal install but
>>> we just comment them out in roller.properties.
>>
>> Or we could have an admin page to enable them like for editor pages.
>>
>> -- Sean
Re: cleanup weblog entries plugins
Posted by Allen Gilliland <al...@sun.com>.
for the current set of plugins I think that's fine, we can just move all
the current plugins in to the core src tree and then modify the config
to only enable a subset of them. i'll go ahead and take this approach
since it really is the easiest in our current situation.
the main reason i proposed this though is that i believe very strongly
that moving forward it's not our job to maintain all the plugins
directly in the src tree. we don't have many people who do this right
now, but eventually we want to build a user community that really does
create and share plugins and that has to happen outside of the core
project. we already have 10 plugins, what happens if the list grows to
20, 50, etc?
as long as we make it easy for people to add in a plugin then i think
it's best that they be developed and maintained outside of the core src.
-- Allen
Sean Gilligan wrote:
> Anil Gangolli wrote:
>>
>> Sorry for entering this conversation a bit late.
>>
>> How about shipping these plugins but not enabling them by default.
>> For example, I'd rather they ship as part of the normal install but we
>> just comment them out in roller.properties.
>
> Or we could have an admin page to enable them like for editor pages.
>
> -- Sean
Re: cleanup weblog entries plugins
Posted by Sean Gilligan <se...@msgilligan.com>.
Anil Gangolli wrote:
>
> Sorry for entering this conversation a bit late.
>
> How about shipping these plugins but not enabling them by default. For
> example, I'd rather they ship as part of the normal install but we just
> comment them out in roller.properties.
Or we could have an admin page to enable them like for editor pages.
-- Sean
Re: cleanup weblog entries plugins
Posted by Anil Gangolli <an...@busybuddha.org>.
Sorry for entering this conversation a bit late.
How about shipping these plugins but not enabling them by default. For
example, I'd rather they ship as part of the normal install but we just
comment them out in roller.properties.
I don't mind reorganizing them into a different package and even a different
jar but I'd really like to ship them along with Roller.
--a.
----- Original Message -----
From: "Allen Gilliland" <al...@sun.com>
To: <ro...@incubator.apache.org>
Sent: Thursday, August 31, 2006 9:07 AM
Subject: Re: cleanup weblog entries plugins
>
>
> Dave Levy wrote:
>> I can see why you create your lists as you do, but I agree with both the
>> amendments. I use the topic plugin all the time and occasionally the
>> smiley plugin. (I will document it some time and would use it more if I
>> knew how to invoke some of the odder smileys (particularly the smug
>> one.))
>
> Actually, the smiley plugin would be one of the harder ones to remove
> since it also has images in it, so maybe we should just leave that one as
> well.
>
>
>>
>> I personally think the ConvertLineBreaksPlugin produces terrible HTML and
>> is hard to incorporate into a theme and inhibits the formating of code
>> and tables (which I also oppose in blog articles), so would suggest that
>> it is an extra not core.
>
> I think that's just a case where you do things that don't work well with
> the plugin and so it makes sense that you don't apply it. I still think
> it's valuable to most people and in the years of blogging that I've done
> I'd say that 99% of the time I just write paragraphs and include <A> and
> <IMG> tags and that's it, so this plugin is very useful in simply taking
> plain text paragraphs and converting them to html. I have never once put
> a <table> in an entry and i don't think most people do.
>
>
>>
>> The customers, i.e. people who make the plugins available for use are the
>> site managers, but removing it would mean that people will have to learn
>> HTML. You can survive with <P>, <A> and <IMG> though how hard is that?
>
> The point of removing them from the Roller core is because they are things
> that possibly *shouldn't* be enabled by default, they are plugins and
> hence are meant to be added on to extend functionality. I think that we
> would technically be justified in removing all of them and forcing all
> admins to manually pick and enable all the plugins they want, but that
> seems unreasonable.
>
> So this is what I am going with unless there are other opinions ...
>
> keep in core:
> ConvertLineBreaksPlugin
> ObfuscateEmailPlugin
> TopicTagPlugin
> SimleyPlugin
>
> make optional:
> WikipediaLinkPlugin
> GoogleLinkPlugin
> TextilePlugin
> AcronymsPlugin
> BookmarkPlugin
>
> I plan to do this later today.
>
> -- Allen
>
>
>>
>> Dave Johnson wrote:
>>> On 8/29/06, Allen Gilliland <al...@sun.com> wrote:
>>>> 2. Move all plugins which are shipped with Roller into the core src
>>>> directory so they are actually part of the main build.
>>>>
>>>> 3. Remove all plugins which are *not* going to be shipped with Roller
>>>> from being included in a standard build. They can stay in the contrib
>>>> area and just be built separately, or possibly moved elsewhere like the
>>>> Roller support project.
>>>>
>>>> anyone object to any of these steps?
>>>
>>> +1 on this idea
>>>
>>>> keep in core:
>>>> ConvertLineBreaksPlugin
>>>> BookmarkPlugin
>>>> ObfuscateEmailPlugin
>>>
>>> I'd replace the BookmarkPlugin with TopicTagPlugin, based on popularity.
>>>
>>> - Dave
>>
>
Re: cleanup weblog entries plugins
Posted by Dave Levy <Da...@Sun.COM>.
Alan
I don't disagree with what you say about convertlinebreaks. Its too
useful and used to remove from the core.
Allen Gilliland wrote:
>
>
> Dave Levy wrote:
>> I can see why you create your lists as you do, but I agree with both
>> the amendments. I use the topic plugin all the time and occasionally
>> the smiley plugin. (I will document it some time and would use it
>> more if I knew how to invoke some of the odder smileys (particularly
>> the smug one.))
>
> Actually, the smiley plugin would be one of the harder ones to remove
> since it also has images in it, so maybe we should just leave that one
> as well.
>
>
>>
>> I personally think the ConvertLineBreaksPlugin produces terrible HTML
>> and is hard to incorporate into a theme and inhibits the formating of
>> code and tables (which I also oppose in blog articles), so would
>> suggest that it is an extra not core.
>
> I think that's just a case where you do things that don't work well
> with the plugin and so it makes sense that you don't apply it. I
> still think it's valuable to most people and in the years of blogging
> that I've done I'd say that 99% of the time I just write paragraphs
> and include <A> and <IMG> tags and that's it, so this plugin is very
> useful in simply taking plain text paragraphs and converting them to
> html. I have never once put a <table> in an entry and i don't think
> most people do.
>
>
>>
>> The customers, i.e. people who make the plugins available for use are
>> the site managers, but removing it would mean that people will have
>> to learn HTML. You can survive with <P>, <A> and <IMG> though how
>> hard is that?
>
> The point of removing them from the Roller core is because they are
> things that possibly *shouldn't* be enabled by default, they are
> plugins and hence are meant to be added on to extend functionality. I
> think that we would technically be justified in removing all of them
> and forcing all admins to manually pick and enable all the plugins
> they want, but that seems unreasonable.
>
> So this is what I am going with unless there are other opinions ...
>
> keep in core:
> ConvertLineBreaksPlugin
> ObfuscateEmailPlugin
> TopicTagPlugin
> SimleyPlugin
>
> make optional:
> WikipediaLinkPlugin
> GoogleLinkPlugin
> TextilePlugin
> AcronymsPlugin
> BookmarkPlugin
>
> I plan to do this later today.
>
> -- Allen
>
>
>>
>> Dave Johnson wrote:
>>> On 8/29/06, Allen Gilliland <al...@sun.com> wrote:
>>>> 2. Move all plugins which are shipped with Roller into the core src
>>>> directory so they are actually part of the main build.
>>>>
>>>> 3. Remove all plugins which are *not* going to be shipped with Roller
>>>> from being included in a standard build. They can stay in the contrib
>>>> area and just be built separately, or possibly moved elsewhere like
>>>> the
>>>> Roller support project.
>>>>
>>>> anyone object to any of these steps?
>>>
>>> +1 on this idea
>>>
>>>> keep in core:
>>>> ConvertLineBreaksPlugin
>>>> BookmarkPlugin
>>>> ObfuscateEmailPlugin
>>>
>>> I'd replace the BookmarkPlugin with TopicTagPlugin, based on
>>> popularity.
>>>
>>> - Dave
>>
--
Dave (Dave Levy)
Re: cleanup weblog entries plugins
Posted by Allen Gilliland <al...@sun.com>.
Dave Levy wrote:
> I can see why you create your lists as you do, but I agree with both the
> amendments. I use the topic plugin all the time and occasionally the
> smiley plugin. (I will document it some time and would use it more if I
> knew how to invoke some of the odder smileys (particularly the smug one.))
Actually, the smiley plugin would be one of the harder ones to remove
since it also has images in it, so maybe we should just leave that one
as well.
>
> I personally think the ConvertLineBreaksPlugin produces terrible HTML
> and is hard to incorporate into a theme and inhibits the formating of
> code and tables (which I also oppose in blog articles), so would suggest
> that it is an extra not core.
I think that's just a case where you do things that don't work well with
the plugin and so it makes sense that you don't apply it. I still think
it's valuable to most people and in the years of blogging that I've done
I'd say that 99% of the time I just write paragraphs and include <A> and
<IMG> tags and that's it, so this plugin is very useful in simply taking
plain text paragraphs and converting them to html. I have never once
put a <table> in an entry and i don't think most people do.
>
> The customers, i.e. people who make the plugins available for use are
> the site managers, but removing it would mean that people will have to
> learn HTML. You can survive with <P>, <A> and <IMG> though how hard is
> that?
The point of removing them from the Roller core is because they are
things that possibly *shouldn't* be enabled by default, they are plugins
and hence are meant to be added on to extend functionality. I think
that we would technically be justified in removing all of them and
forcing all admins to manually pick and enable all the plugins they
want, but that seems unreasonable.
So this is what I am going with unless there are other opinions ...
keep in core:
ConvertLineBreaksPlugin
ObfuscateEmailPlugin
TopicTagPlugin
SimleyPlugin
make optional:
WikipediaLinkPlugin
GoogleLinkPlugin
TextilePlugin
AcronymsPlugin
BookmarkPlugin
I plan to do this later today.
-- Allen
>
> Dave Johnson wrote:
>> On 8/29/06, Allen Gilliland <al...@sun.com> wrote:
>>> 2. Move all plugins which are shipped with Roller into the core src
>>> directory so they are actually part of the main build.
>>>
>>> 3. Remove all plugins which are *not* going to be shipped with Roller
>>> from being included in a standard build. They can stay in the contrib
>>> area and just be built separately, or possibly moved elsewhere like the
>>> Roller support project.
>>>
>>> anyone object to any of these steps?
>>
>> +1 on this idea
>>
>>> keep in core:
>>> ConvertLineBreaksPlugin
>>> BookmarkPlugin
>>> ObfuscateEmailPlugin
>>
>> I'd replace the BookmarkPlugin with TopicTagPlugin, based on popularity.
>>
>> - Dave
>
Re: cleanup weblog entries plugins
Posted by Dave Levy <Da...@Sun.COM>.
I can see why you create your lists as you do, but I agree with both the
amendments. I use the topic plugin all the time and occasionally the
smiley plugin. (I will document it some time and would use it more if I
knew how to invoke some of the odder smileys (particularly the smug one.))
I personally think the ConvertLineBreaksPlugin produces terrible HTML
and is hard to incorporate into a theme and inhibits the formating of
code and tables (which I also oppose in blog articles), so would suggest
that it is an extra not core.
The customers, i.e. people who make the plugins available for use are
the site managers, but removing it would mean that people will have to
learn HTML. You can survive with <P>, <A> and <IMG> though how hard is that?
Dave Johnson wrote:
> On 8/29/06, Allen Gilliland <al...@sun.com> wrote:
>> 2. Move all plugins which are shipped with Roller into the core src
>> directory so they are actually part of the main build.
>>
>> 3. Remove all plugins which are *not* going to be shipped with Roller
>> from being included in a standard build. They can stay in the contrib
>> area and just be built separately, or possibly moved elsewhere like the
>> Roller support project.
>>
>> anyone object to any of these steps?
>
> +1 on this idea
>
>> keep in core:
>> ConvertLineBreaksPlugin
>> BookmarkPlugin
>> ObfuscateEmailPlugin
>
> I'd replace the BookmarkPlugin with TopicTagPlugin, based on popularity.
>
> - Dave
--
Dave
<http://www.sun.com> * David Levy *
*Sun Microsystems Ltd.*
55, King William St.,
London EC4R 9ND United Kingdom
Phone +44 (0) 20 7469 9908/x18308
Mobile +44 (0) 7710-360922
Blog http://blogs.sun.com/DaveLevy
Email David.Levy@Sun.COM
Sun Proprietary & Confidential . This e-mail message is for the sole use
of the intended recipient(s) and may contain confidential and
privilidged information. Any unauthorised review, use, disclosure or
distribution is prohibited. If you are not the intended recepient,
please contact the sender by reply e-mail and destroy all copies of the
original message.
Re: cleanup weblog entries plugins
Posted by Dave Johnson <sn...@gmail.com>.
On 8/29/06, Allen Gilliland <al...@sun.com> wrote:
> 2. Move all plugins which are shipped with Roller into the core src
> directory so they are actually part of the main build.
>
> 3. Remove all plugins which are *not* going to be shipped with Roller
> from being included in a standard build. They can stay in the contrib
> area and just be built separately, or possibly moved elsewhere like the
> Roller support project.
>
> anyone object to any of these steps?
+1 on this idea
> keep in core:
> ConvertLineBreaksPlugin
> BookmarkPlugin
> ObfuscateEmailPlugin
I'd replace the BookmarkPlugin with TopicTagPlugin, based on popularity.
- Dave