Hi Blue, > 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 solved. 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 :) Dom
