Michael Rueger writes: > Hi all, > > while working on a new (Open)Sophie release I ran into the problem of > where to put some plugin code. In this case it is for the Curl Plugin, > which Steven Riggins ported into Sophie, but the problem is pretty > common I would guess. > > So the problem is this (as illustrated using our Curl package): > > - we have a package Sophie-Curl, which includes the Squeak Curl client > and the CurlPlugin class. > - loaded into a "normal" image, the CurlPlugin ends up being a subclass > of ProtObject as the superclass is missing. > - now we separate it into Sophie-Curl and Sophie-Curl-Plugin, but that > won't fly with the MC name matching > - so we name it Sophie-Curl and Sophie-Plugin-Curl > > I think that is ugly. > > 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?
Why not just add the plugin's to the VMMaker package? I don't see any gain for having another official plugin package besides VMMaker. It'll have the main problem and advantage of VMMaker of central ownership. Having a Universes package that builds a standard VM building image would be a useful step forward. The packages for all standard Pharo packages could be included automatically. I'm doing something like this with the exupery-dev Universes package, just remove the Exupery elements if you're not interested in that. Bryce _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
