Subject: Re: plugin loading
From: Dom Lachowicz (email@example.com)
Date: Thu Oct 25 2001 - 08:57:15 CDT
> Problem faced is that for varied reasons (end-user ignorance, strict
> perms which are of course uncontrollable, system lib incompatibilities,
> and others) it is impossible to include a plugin in distribution (the
> verb, not the linux term to which it also applies due to the laws of
> communicatory language). Take that, dont argue :).
Umm.. and if I argue? :-P
People have been including plugins in distribution for a variety of systems
since the advent of dlopen(). There are simple work-arounds and solutions for
all of the problems you've listed above:
1) System lib incompatibilities: for example, all RH6.x versions are
compatible, all RH7.x versions are compatibile. We make 2 different binaries,
one for each major release version. Also, for example, any abi plugin built on
Windows should work on *any* windows version >= 95 "just because". Problem
2) End-user ignorance: somehow I don't buy this. Certain plugins which are
considered "really cool to have and useful to the comman man" will be shipped
with Abi by default, like the import/export plugins. This is much like how
Netscape will ship a Java and RealPlayer plugin by default. However, for
people who want that additional exotic plugins (Abi:thesaurus, Netscape:ogg
vorbis audio support), they're generally smart enough to go and find/install
the plugin and any dependencies that it might have.
3) Strict perms: Those who can't won't. Those who can will. Those with strict
enough perms won't even be able to install Abi, theoretically... Even then,
the Unix build of Abi will load plugins from your ~/.AbiSuite directory, thus
avoiding polluting the "system namespace"
> The only universal way to let different systems (win, lin, bsd, diff
> distros, etc) handle plugins that are included in distribution is for
> the builder to specify a directory for abi to look in every time she is
> loaded (or maybe if someone clicks 'reload plugins' or something) to
> register plugins. That way the user can download and load a plugin from
> the dialogue as now from any dir he has access to or...
Not really. People on *NIX ensure that their stuff gets put into specific
directories all the time - /usr/share/myprog, /usr/lib/myprog, ~/.myprog/, ...
Abi already looks in a specific directory every time it is loaded (2
directories, actually). By ensuring that plugins get installed there and
*only* there, we're reducing the number of headaches that we have to deal with
and phony bug-reports at a minimal expense to the person writing the installer
file. Further, it is (unfortunately) highly doubtful that we're going to be
seeing many (any?) third-party plugins for various reasons, so I doubt that
this is even an issue (i consider AikSaurus "in-house" - it's even located by
the AbiWord CVS server).
> Arguments: 1) Performance. <argument> plugin loading time will be half
> the startup time</argument> <response> time to load any real-world
> plugin is negligible, microscopic. and there aren't even that many
> plugins that you can put in your plugin dir. Also, each distro or
> branch-distro has its own target audience (win9+->Pent, elks->286, etc)
> so they can choose what is reasonable to include.</response>
Completely correct. It might make more sense to ship a DOC reader plugin on
Win32 and not on Linux, or at least have a check-box in an installer
"intelligently" defaulted based on the user's system. Plugin loading time is
negligable, and startup time is typically a *minute* fraction of total running
time. Abi already loads faster than emacs and almost as fast as vi on Linux.
That's fscking fast for a word-processor (or anything, for that matter), and
plugins aren't likely to put much of a dent into our startup performance.
> Blah blah blaah.
Wonderful argument :)
This archive was generated by hypermail 2b25 : Thu Oct 25 2001 - 08:57:26 CDT