Re: [Pharo-project] Plugin organization

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Plugin organization

David T. Lewis
 
On Wed, Jan 21, 2009 at 02:05:46PM +0100, Michael Rueger wrote:
m Hi all,

>
> What I would like to propose is that we organize all plugins in Pharo in
> to a Plugin category.
> So we would then have "Plugin-Curl", "Plugin-Locale" etc. Or
> alternatively "Plugin-Network-Curl", "Plugin-System-Locale" etc.
>
> That would also allow to simply load all plugins into a VMMaker image by
> using a package "Plugin".
>
> What do you guys think?

+1 on a common naming convention for this.

I would also like to suggest something to distinguish VM plugins
from other kinds of "plugins". The reason is that the word "Plugin"
is used to describe the web browser plugin, and maybe other things
in the future. If we say "VmPlugin" or "VMConstruction-Plugin-*
then the difference is clear.

I checked an older Squeak image to remind myself of the original
naming convention, which was:

        VMConstruction-Interpreter
        VMConstruction-Translation
        VMConstruction-Plugins
        VMConstruction-B3DSimulation
        VMConstruction-TestPlugins
        VMConstruction-Applescript

Some older plugins that are maintained outside of the VMMaker
package already use this package naming convention, hence:

        VMConstruction-Plugins-OSProcessPlugin
        VMConstruction-Plugins-XDisplayControlPlugin
        VMConstruction-Plugins-AioPlugin

This still looks perfectly good to me, so how about just using
"VMConstruction-Plugins-*" rather than "Plugins-*"?

Michael Rueger proposed Plugin-* and Tests-*, so guess that
this would be:

        VMConstruction-Plugins
        VMConstruction-Tests

or is it "Tests-VMConstruction-Plugins" ?? I am not sure.

(cc to vm-dev list)

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Re: [Pharo-project] Plugin organization

Andreas.Raab
 
David T. Lewis wrote:
> Some older plugins that are maintained outside of the VMMaker
> package already use this package naming convention, hence:
>
> VMConstruction-Plugins-OSProcessPlugin
> VMConstruction-Plugins-XDisplayControlPlugin
> VMConstruction-Plugins-AioPlugin
>
> This still looks perfectly good to me, so how about just using
> "VMConstruction-Plugins-*" rather than "Plugins-*"?

Maybe I'm missing something but how is any of this different from
VMMaker-Plugins which is the current categorization for plugins?

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Re: [Pharo-project] Plugin organization

David T. Lewis
 
On Sat, Jan 31, 2009 at 11:38:26AM -0800, Andreas Raab wrote:

>
> David T. Lewis wrote:
> >Some older plugins that are maintained outside of the VMMaker
> >package already use this package naming convention, hence:
> >
> > VMConstruction-Plugins-OSProcessPlugin
> > VMConstruction-Plugins-XDisplayControlPlugin
> > VMConstruction-Plugins-AioPlugin
> >
> >This still looks perfectly good to me, so how about just using
> >"VMConstruction-Plugins-*" rather than "Plugins-*"?
>
> Maybe I'm missing something but how is any of this different from
> VMMaker-Plugins which is the current categorization for plugins?

The classes in category VMMaker-Plugins-OSProcessPlugin would then
appear as part of the VMMaker package. If someone was maintaining
VMMaker with Monticello, and also had OSProcessPlugin (or whatever)
in their image, they would not want OSProcessPlugin to be saved as
part of the VMMaker package.

I am assuming that the plugins currently in VMMaker-Plugins will
stay there unless someone someone specifically takes maintenance
responsibility for them outside of their current home. I was also
assuming that the original naming suggestion on the pharo list
refers to plugins not currently in VMMaker (but I am not involved
with pharo so I guess I'm not certain if that is the intent).

So to summarize: If someone is going to have a new package name
for plugins outside of "VMMaker-*", it should not be called
"Plugin-*" because the name could be misleading, and it might
as well be called "VMConstruction-Plugins-*" because it is a
good name that has been in use for many years for this purpose.

Just my $0.02

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Re: [Pharo-project] Plugin organization

Andreas.Raab
 
David T. Lewis wrote:

>>> This still looks perfectly good to me, so how about just using
>>> "VMConstruction-Plugins-*" rather than "Plugins-*"?
>> Maybe I'm missing something but how is any of this different from
>> VMMaker-Plugins which is the current categorization for plugins?
>
> The classes in category VMMaker-Plugins-OSProcessPlugin would then
> appear as part of the VMMaker package. If someone was maintaining
> VMMaker with Monticello, and also had OSProcessPlugin (or whatever)
> in their image, they would not want OSProcessPlugin to be saved as
> part of the VMMaker package.

I see. If that's the issue I would probably argue to split up VMMaker
(it's too big as it stands for my taste) perhaps into
VMMaker-Translation (CCodeGen, Slang), VMMaker-Interpreter
(ObjectMemory, Interpreter), and VMMaker-Plugins (all the plugins with
the common ones being in VMMaker-Plugins-Common). In which case
VMMaker-Plugins-OSProcess could live side by side with the rest of the
VMMaker packages.

Cheers,
   - Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Re: [Pharo-project] Plugin organization

David T. Lewis
 
On Sat, Jan 31, 2009 at 03:26:13PM -0800, Andreas Raab wrote:

>
> David T. Lewis wrote:
> >>>This still looks perfectly good to me, so how about just using
> >>>"VMConstruction-Plugins-*" rather than "Plugins-*"?
> >>Maybe I'm missing something but how is any of this different from
> >>VMMaker-Plugins which is the current categorization for plugins?
> >
> >The classes in category VMMaker-Plugins-OSProcessPlugin would then
> >appear as part of the VMMaker package. If someone was maintaining
> >VMMaker with Monticello, and also had OSProcessPlugin (or whatever)
> >in their image, they would not want OSProcessPlugin to be saved as
> >part of the VMMaker package.
>
> I see. If that's the issue I would probably argue to split up VMMaker
> (it's too big as it stands for my taste) perhaps into
> VMMaker-Translation (CCodeGen, Slang), VMMaker-Interpreter
> (ObjectMemory, Interpreter), and VMMaker-Plugins (all the plugins with
> the common ones being in VMMaker-Plugins-Common). In which case
> VMMaker-Plugins-OSProcess could live side by side with the rest of the
> VMMaker packages.

I agree that splitting up VMMaker might be be a good idea. I don't
know if this is a good time to address the issue or not (there are
some important VM projects under way, such as cog, and I don't know
if reorganizing VMMaker would help or hurt).

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Re: [Pharo-project] Plugin organization

Eliot Miranda-2
 


On Sun, Feb 1, 2009 at 6:46 AM, David T. Lewis <[hidden email]> wrote:

On Sat, Jan 31, 2009 at 03:26:13PM -0800, Andreas Raab wrote:
>
> David T. Lewis wrote:
> >>>This still looks perfectly good to me, so how about just using
> >>>"VMConstruction-Plugins-*" rather than "Plugins-*"?
> >>Maybe I'm missing something but how is any of this different from
> >>VMMaker-Plugins which is the current categorization for plugins?
> >
> >The classes in category VMMaker-Plugins-OSProcessPlugin would then
> >appear as part of the VMMaker package. If someone was maintaining
> >VMMaker with Monticello, and also had OSProcessPlugin (or whatever)
> >in their image, they would not want OSProcessPlugin to be saved as
> >part of the VMMaker package.
>
> I see. If that's the issue I would probably argue to split up VMMaker
> (it's too big as it stands for my taste) perhaps into
> VMMaker-Translation (CCodeGen, Slang), VMMaker-Interpreter
> (ObjectMemory, Interpreter), and VMMaker-Plugins (all the plugins with
> the common ones being in VMMaker-Plugins-Common). In which case
> VMMaker-Plugins-OSProcess could live side by side with the rest of the
> VMMaker packages.

I agree that splitting up VMMaker might be be a good idea. I don't
know if this is a good time to address the issue or not (there are
some important VM projects under way, such as cog, and I don't know
if reorganizing VMMaker would help or hurt).

I'll give it some thought soon.  I'm hoping to put out a Cog release soon and will make sure to decompose it when I do.
Eliot
 


Dave