Re: commit: abi & abiword-plugins: simple plugin interface

From: Kenneth J.Davis (
Date: Tue Jul 16 2002 - 04:12:31 EDT

  • Next message: Jesper Skov: "Re: AbiWord Weekly News - further on the subscription idea"

    Andrew Dunbar <> wrote on 7/16/2002 3:41:30 AM:
    >--- F J Franklin <>
    >wrote: > > I really don't think we want to do this.
    >> only
    >> Anyway, I agree that best results can only be got by
    >> interacting directly
    >> with AbiWord's internals. But the purpose behind SPI
    >> is a passive
    >> "C"-style interface whereby AbiWord calls functions
    >> defined in the plugin
    >> and *not* vice-versa. Kenneth's CAPI is more likely
    >> to provide interaction
    >> bewteen plugin and abiword.

    My AbiCapi is more of a shim between AbiWord and the
    plugin, where AbiWord can still directly call into
    the plugin, and does so to register it [1], but
    the plugin does not call directly into AbiWord, it
    instead goes through a C->C++ mapping API, where
    AbiCapi impliments a C interface [2] that either
    maps directly to an AbiWord C++ call or is a convenience
    function that maps into a sequence of AbiWord C++
    calls that performs some action.

    [1] technically, I have a generic implementation
    that is actually called for [un]registration, so as to ease
    the loading of AbiCapi and perform the imports, which then
    calls to a user defined function to do the plugin's registering;
    but from AbiWord's perspective it is no different.

    [2] my main reason for AbiCapi is to eliminate implicit
    linking and provide a reasonably stable API (the plugins
    are still tied to AbiWord's internals, just more loosely).
    C is used to prevent name mangling and use of
    different compiled classes (reduce binary dependence);
    So far my actual API implemented is largely just a
    C wrapper over C++ calls; so nearly any aspect currently
    exported by AbiWord can be used, if an appropriate
    wrapper function is defined.

    Whether my AbiCapi plugin proves to be worthwhile or
    not is still questionable. Although I have successfully
    used it for all [on Windows] tools plugins and graphics
    importers. I'm presently converting ScriptHappy over
    to it, and then I'll tackle importers/exporters.

    >> The interface below does lend itself easily to some
    >> simple conversions
    >> such as compression/decompression and
    >> encryption/decryption. Also,
    >> perhaps, things like bad Cocoa RTF <-> proper RTF -
    >> but I don't know about
    >> that.
    >Yes it does sound like it has some good uses.
    >I definitely think there is a good idea in here
    >somewhere. I just wanted to warn people about
    >potential lossiness in the general case.
    >Andrew Dunbar.
    >> >> extern "C" [...] int
    >> >> convert_document (const unsigned char *

    The above may actually be what I'm looking for,
    for some of the plugins that just wrap an existing
    importer with some sort of compression; additionally
    I'll probably implement some proxy objects and more
    wrapper/convenience functions. Just guessing though.
    Time permitting I'll get some importers/exporters
    converted to using AbiCapi later this week and write
    some documentation for those interested in playing with


    Jeremy Davis

    This archive was generated by hypermail 2.1.4 : Tue Jul 16 2002 - 04:58:46 EDT