Jérôme WAGNER wrote:
> Hello,
>
> I think plugins dir architecture should solve 2 problems :
>
> - the separation of extension points
> - the easiness of installation across extension points
>
> Let me explain :
>
> 1/ A plugin for the wenbox should not lie in a directory where we look for
> audio-codecs plugin
>
> 2/ a "file transfer" plugin that might be composed of
> - a phapi plugin
> - a presentation plugin
> - a model plugin
>
> should present "cohesion" : all the files should be removable by only one
> dir.
>
> A way to solve that in the mid-term is the following :
>
> 1/ define sticky directory names for extension points like :
> - plugin-wenbox
> - plugin-phapi-audio-codec
> - plugin-phapi
> - ...
>
> 2/ have the loader scan recursively a "plugins" directory for all
> appearances of the sticky names and reference those directory for potential
> presence of the required plugin
>
> 3/ we could potentially accept to scan elsewhere on the machine and I
> suggest we put a ow prefix in front of the entry points
>
> Ow is the prefix we use for all disambiguiation so it looks good also here
> (it is short and meaningful)
>
> ----------
>
> At this stage (because we do not have so many plugins and they all are
> limited to 1 file), I suggest we simplify this approach and choose
>
> {Basedir}/
> |
> |- ow_plugins/
> |-ow_plugin_wenbox
> |-ow_plugin_phapi_audio_codec
> |-ow_plugin_phapi_video_codec
>
> We can probably live with this architecture a few month.
"basedir" is already the "plugin dir". So we should name it like in the
config to pluginPath. On Linux the pluginPath is /usr/lib/wengophone. On
Windows the pluginPath is ./plugins from the view of the executable. I
don't think that that the ow_plugin prefix is needed. On windows it is
in the same dir as the rest on linux you have the application name in
the path. I don't know about MacOSX.
pluginPath
|
|- wenbox
|- wenboxplugin.so
|- phapi
|- audio
|- phspeexplugin.so
|- phamrplugin.so
|- video
I think this is the best structure. I'll implement it if you give me the OK.
>
> Are you ok with that ?
>
> Jerome
> Ps: there are quite some things to do for packagers if we decide that. It
> would be good to list all the impacts of such a directory renaming.
>
I'm a packager that's why I want to implement it as soon as possible.
Plugins have to be in /usr/lib/application_name.
-- andreas
>
>
>
>
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] De la part de Andreas
> Schneider
> Envoyé : mercredi 27 septembre 2006 09:41
> À : wengophone-devel@lists.openwengo.com
> Objet : [Wengophone-devel] WengoPhone default plugin directories
>
> Hi,
>
> I want clear or lets say better directories for plugins. We could use
> one directory for all plugins or use a base directory and subdirectories
> for different parts.
>
> The base directory
> ===================
>
> Linux
> ------
> Hardcoded (cmake option):
>
> _prefix/_libdir/wengophone (/usr/lib64/wengophone)
>
> Dynamic:
>
> Path::getApplicationDirPath()
>
> Windows
> --------
>
> Path::getApplicationDirPath() + File::getPathSeparator() +
> "plugins"
> + File::getPathSeparator()
>
> MacOSX
> -------
>
> Path::getApplicationPrivateFrameworksDirPath() +
> File::getPathSeparator() + "plugins" + File::getPathSeparator()
>
>
> If we want subdirs:
>
> plugins/phapi
> plugins/wenbox
>
>
> What do you want?
>
> -- andreas
>
--
http://www.cynapses.org/ - cybernetic synapses
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Wengophone-devel mailing list Wengophone-devel@lists.openwengo.com http://dev.openwengo.com/mailman/listinfo/wengophone-devel
