Ethan A Merritt wrote:
> On Sunday 24 September 2006 11:48 am, Timoth=E9e Lecomte wrote:
>>>> - write a plugin interface to gnuplot, so that the wxWidgets is
>>>> dynamically loadable and can be distributed separately
>>> That would be the best.
>> Technically the best, but arguably not for the user, since he would ha=
>> to find it in the distribution package manager...
> I don't think that by itself is a problem. People are used to downloadi=
> and installing extension plugins for their web browser, video/audio plu=
> for their media player, filter plugins for their word processor, etc.
> They should be able to handle terminal plugins for gnuplot.
Of course, they can, but do they really want ? When you want to do=20
scientific work, you already spend so much time learning languages for=20
computation purposes (whether it is C, C++, Fortran, Python, Octave or=20
whatever) that you are pleased when something works directly. There are=20
few exceptions. The best program is the one that gives 90% of its full=20
power with the default installation.
Octave people are currently implementing a "package manager", because=20
they have so many additional and less tested code in Octave Forge that=20
they need a plugin system to make them easily available.
Firefox as a browser made part of its success with the extensions, but=20
it's because they have a well-thought distribution system for them,=20
because the original application is very good, and because the community=20
is vary active writing those extensions. Ultimately, interesting=20
extensions are cleaned/rewritten and integrated.
That's not really the case for gnuplot. We are currently discussing=20
plugins because of dependencies issues. vlc (a media player) is another=20
example of application based on plugins, and like gnuplot it is to make=20
backend support more flexible. The main one is in wxWidgets by the way.=20
But even if the app is architectured around these plugins, in practise=20
it is simply distributed with the few main backends and that's all.
In our case, I do think wxWidgets is a well-thought dependency. Gtk=20
would have been a good choice too, though, and has the big advantage to=20
be very widely distributed on Linux. That's why I was offering to work=20
on that if needed.
If we choose to implement plugins, we should provide distribution=20
guidelines. For example, we can encourage distributions to install by=20
default the full package, but to allow (if they want) the user to=20
install stripped-down versions. That's what Debian is is doing right=20
now: there's one package with the x11 binary (gnuplot-x11) and one with=20
the gnuplot binary (gnuplot-nox), but the default 'gnuplot' package just=20
installs the two of them. Somebody who only wants the core can install=20
Maybe we can satisfy Fedora that way, maybe not. I'm quite sure the=20
trend is not to multiply packages. And I would like to see full packages=20
> I think the bigger hurdle is portability. Implementing a plugin system
> for linux would be easy. But we'd have to do it all over again for=20
> Solaris, OSF, Irix, Windows, OSX, etc. Or perhaps there is a=20
> multi-platform plugin infrastructure that I am unaware of?
From the GModule documentation in GLib=20
"These functions provide a portable way to dynamically load object files=20
(commonly known as 'plug-ins'). The current implementation supports all=20
systems that provide an implementation of ||dlopen()|| (e.g. Linux/Sun),=20
as well as HP-UX via its ||shl_load()|| mechanism, and Windows platforms=20
(OSX is just another Unix)
If we had to choose a general-purpose library to depend on, I think GLib=20
would be the best choice (then we also get a lot of other useful=20
cross-platform functions, such as threads).
> We discussed this issue briefly quite a while ago, with regard to patch
> #588805 external functions via plugins
> I like the idea of plugins, but implementation is non-trivial.
Non-trivial, but it can be done cleanly with GLib. See=20
http://blog.eikke.com/index.php/ikke/2005/05/18/gmodules_are_fun for an=20
> However, ...
> I can think of one more alternative. If the wxt terminal code were
> broken out into a separate executable, equivalent to gnuplot_x11,=20
> then the core gnuplot binary would not need to be linked against
> pango/cairo/wxWidgets. The extreme case of this would be=20
> teaching the wxt code to understand the same piped binary stream
> format that goes between gnuplot <---> gnuplot_x11. Then we'd
> have a binary pipe API shared by multiple terminal types.
> The library dependencies would not pertain to the core gnuplot
> binary, only to the parallel helper programs.
Pipes are probably as specific to the platforms as dynamic libraries=20
are. Moreover, they add an additional bottleneck (not that big if the=20
protocal is binary, I admit). Plugins are probably better. If we decide=20
to implement plugins, the x11 terminal could be a plugin without the=20
need to use pipes...
Anyway, although I see clearly the technical aspects, I'm still as much=20
puzzled about the _choices_ that we should make. Plugins or not ?
(if you have other reasons besides distributions concerns, please speak=20
Maybe the best is to see how the current implementation choice is=20
handled by distributions. Let's release 4.2 as it is, and give some time=20
to see what distributions do with it. If there's something wrong (if the=20
wxWidgets terminal is _never_ used for example), then we can still=20
address it later. The world won't crash because of it.