Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Specify plugin directory #695

Closed
unnonouno opened this Issue · 14 comments

3 participants

@unnonouno
Owner

I want to change a plugin directory on runtime.
How about use an environment variable, such as JUBATUS_PLUGIN_PATH?

@kmaehashi
Owner

I think paths in LD_LIBRARY_PATH will be looked-up via dlopen.

@kmaehashi kmaehashi added this to the Far Future milestone
@kmaehashi
Owner

From discussion in meeting in 2014-03-03:

  • It's better to use specific environment variable like JUBATUS_PLUGIN_PATH instead of LD_LIBRARY_PATH, which is usually expected to be used for program invocation.
  • How about investigating other programs with plug-in features?
  • Contribution wanted!
@unnonouno
Owner

First we need to the current specification.
jubatus/website#123

@kmaehashi
Owner

Related to #713:

Giving basename to dlopen is ambiguous.

How about trying in this order?

  1. If absolute or relative path is given in config, try it.
  2. When failed, and if JUBATUS_PLUGIN_PATH environment variable is available, try JUBATUS_PLUGIN_PATH + basename.
  3. When failed, try JUBATUS_PLUGIN_DIR (compile-time option) + basename.
  4. When failed, raise exception.

In this way, we can tell the exact path to the library when loading it.
This also means LD_LIBRARY_PATH etc. to be ignored.

@tkng
Owner

Hi,

I think it is good to follow the conventions of the famous OSS like Gtk+.

Gtk+ provides an environment variable GTK_PATH. In a nutshell, when the variable is set, Gtk+ loads plugins under the path. If not set, Gtk+ loads plugins under the default path (determined when Gtk+ was configured.)

Detailed behavior of Gtk+ is somewhat complex, so please see the following URL:

https://developer.gnome.org/gtk3/stable/gtk-running.html

@unnonouno
Owner

I also think using LD_LIBRARY_PATH is a bad idea. It is confusing.
@kmaehashi 's idea and @tkng 's idea are same, aren't they?

I also found some plugin frameworks:
http://boost-extension.redshoelace.com/docs/boost/extension/index.html
http://www.codeproject.com/Articles/20648/DynObj-C-Cross-Platform-Plugin-Objects

@tkng
Owner

I agree, @kmaehashi 's idea and my idea seems almost same.

@kmaehashi kmaehashi modified the milestone: 0.5.4, Far Future
@unnonouno unnonouno was assigned by kmaehashi
@unnonouno
Owner

How about like this:

  1. When absolute or relative path is given (that means the path contains '/')
    • Use the path directly (dlopen does not use LD_LIBRARY_PATH in such case)
  2. Otherwise
    • Try to load from JUBATUS_PLUGIN_PATH environment variable if it is set
    • Try to load from JUBATUS_PLUGIN_DIR (compile-time option)

Do we need to use basename?

@kmaehashi
Owner

@unnonouno I agree with the spec!

Do we need to use basename?

I don't think it is not needed as it's confusing.

@unnonouno
Owner

I mean when a user uses a relative or absolute path, do we need to try to load a plugin from the plugin paths with its basename? In such case, a user want to load only from the current directory or the absolute path, isn't it?

@unnonouno
Owner

In other word, when a user fails to write the correct path, Jubatus fails to load it, and if an old version of the same plugin locates in jubatus plugin path, Jubatus loads it. Is that expected behavior?

@kmaehashi
Owner

@kmaehashi, @kumagi will review the spec.

@kmaehashi
Owner

In other word, when a user fails to write the correct path, Jubatus fails to load it, and if an old version of the same plugin locates in jubatus plugin path, Jubatus loads it. Is that expected behavior?

I think it is better to raise error in that case, rather than silently using basename.

@unnonouno
Owner

:+1: I agree with you.

@unnonouno unnonouno closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.