Re: [Ekiga-devel-list] HEAD has issues...

[Craig Southeren <craigs postincrement com>]

On Mon, 11 Sep 2006 07:42:49 +0200
Julien PUYDT <jpuydt free fr> wrote:

..deleted

> > Here is what the current code does:
> > 
> > a) If PWLIBPLUGINDIR is set, set the plugin search path to this value
> > and go to step d)
> > 
> > b) Get the directory containing the executable and put that into the
> > plugin search path
> 
> This is bad on non-win32.

It's both good and not good.

It's very useful for deployment - it means that you can have a single
directory with the application and all of the plugins with no extra work
required.

It's bad because sometimes the local directory contains other stuff
including lots of subdirectories.

While writing this, I'm thinking that perhaps searching the local
directory without recursion might be a good idea.

I'm not sure there is a single good answer here.
 
> > c) Append the value of P_DEFAULT_PLUGIN_DIR to the search path
> 
> This appending looks wrong.

What part looks wrong? 
 
> > d) Assume the plugin search path is a list of directories and search
> > each directory recursively.
> > 
> > The differences between Unix and Windows are:
> > 
> > - The seperator between path elements is ":" on Unix and ";" on Windows
> 
> DIR_SEP is nice to handle that.

Not sure what you mean here.

DIR_SEP (as a macro) is defined and used in pluginmgr.cxx
 
> > - The default value for P_DEFAULT_PLUGIN_DIR is "C:\PWLIB_PLUGINS" on
> > Windows and ".:/usr/lib/pwlib: on Unix
> > 
> > The easiest way to search a user-specific search path for plugins is to
> > ask the user to set the PWLIBPLUGINDIR variable to $(HOME)/pwlib_plugins.
> > However, I guess we can add parsing to this code so that we can specify
> > "~/pwlib_plugins" or some such, where "~" corresponds to the users home
> > directory.
> 
> The easiest for us. Most users are unable to set an environment 
> variable. And remember that on unix, setting PWLIBPLUGINDIR in a shell, 
> makes it available only in that shell!
> 
> We should check if freedesktop.org has a specification for such things 
> (it has one for configuration options), as it's probably the sanest 
> thing to use on unix-like systems.

I'm open to implementing a standard if it makes sense and the code is
not too difficult.
 
> > I agree that removing "." from the default plugin path for Unix is
> > probably a good idea as users often run programs in a directories that
> > have large sub-trees. It was removed from the Windows default value for
> > that very reason.
> 
> Then I would say : let's remove it from cvs right now, as a quick fix to 
> the issue, while we get to think about a sane replacement for that scheme.

The plugin search code has been used for the last year or so for all
plugins (including the audio and video devices) on both OPAL and
OpenH323. I'm not sure why this has suddenly become an issue that needs
an immediate "patch"

I'd like to know what has changed before I start modifying existing code
to fix "problems"

> You mentioned writing new code for plugin searching (which seemed to 
> have something to do with the H.263 plugin) ; could you be more specific?

The H.263 plugin codec is a straight port of the old embedded H.263
codec. This code loaded the file libavcodec.so at runtime to get access
to the ffmpeg functions. The plugin does the same thing, because I
didn't want want to embed the ffmpeg code into the plugin.

When the codec was part of OPAL, it used the same plugin loader code as
PWLib and so it searched the same path. Now that the plugin is seperate
code, it needs to implement the same search mechanism internally.

   Craig

-----------------------------------------------------------------------
 Craig Southeren          Post Increment ? VoIP Consulting and Software
 craigs postincrement com au                   www.postincrement.com.au

 Phone:  +61 243654666      ICQ: #86852844
 Fax:    +61 243656905      MSN: craig_southeren hotmail com
 Mobile: +61 417231046      Jabber: craigs jabber org

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting