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

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

  • Next message: Kenneth J.Davis: "Re: commit: abi & abiword-plugins: simple plugin interface"

    I just realized I forgot to actually send this. :-)

    F J Franklin <> wrote on 7/15/2002 6:21:20 AM:
    >> Today I've
    >> gone through and tried to figure out what was causing memory leaks
    >> (per the debug dump at AbiWord.exe exit), which it ended up being that
    >> the plugins were never unloaded, so they didn't get a chance to cleanup.
    >> I'm going to apply a fix shortly, without which trying to use the
    >> link-grammar plugin will make AbiWord appear locked on exit in a debug
    >> build as it tries to show all the memory never free'd.
    >I was slightly puzzled before by the

    I think this was just a safety check/notification for if the
    plugins failed to unload, as such failures could result in
    resource leaks.

    >which I've just changed, taking the statement out of the assert. Does this
    >mean that plugins never unloaded in non-debug builds?

    At least on Windows as best as I can tell, plugins previously were not
    unloaded in either debug nor non-debug builds. The vector containing
    the plugins was free'd, but the plugins themselves were never given
    the chance to unregister.

    >Anyway, they should now. Also, the Spider is almost finished now.
    >wp/ap/*/ap_*App.cpp need to be updated to call
    >XAP_ModuleManager::instance().registerPending() after loading the
    >> What are your ideas [API you've been considering] for supporting importers
    >> and exporters?
    >Document import/export poses a real challenge. The only API I've been
    >considering for that is the simple convert unknown format to known format
    >(TEXT, RTF, DOC, AWML, + maybe eventually [XP]HTML), i.e.
    >extern "C" [...] int
    >convert_document (const unsigned char * source_buffer,
    > unsigned long source_length,
    > const char * source_content_type,
    > unsigned char ** buffer,
    > unsigned long * length,
    > char ** content_type);

    So the plugin instead of directly inserting the data, will simply
    convert it to one of the internal formats? which then can be used
    to actually load the data.

    My present idea is sorta like I did for the graphics importers,
    a proxy object, it extends/impliments the appropriate AbiWord classes
    which contains stub functions that call plugin supplied C functions.
    I'm not so sure this will work though, the importers/exporters have
    a much closer tie to AbiWord's internals than the other plugins.

    >> Load order isn't an issue for me, presently
    >> AbiWord loads the plugin as usual, which has no imports from AbiWord
    >> so that goes well, AbiWord calls the plugins register function, which
    >> then in turn explicitely loads my AbiCapi plugin, which causes it
    >> to be loaded and it does has imports from AbiWord so Windows goes
    >> ahead and resolves them [at least I think thats what happens].
    >If I understand you, the AbiCapi plugin is never explicitly registered
    >as an AbiWord plugin?

    It works both ways. So AbiCapi is a registered plugin, it just
    isn't a requirement at the current time (since I can't guarentee
    load order).

    >> Anyway, I'm just having fun playing with the plugins.
    >it's fun :-)
    >Ciao, Frank
    >Francis James Franklin
    >"No, she really likes me. She told me I look like Britney Spears, and why
    >would you say that to somebody you don't like?"
    > --- Elle Woods


    This archive was generated by hypermail 2.1.4 : Tue Jul 16 2002 - 04:17:35 EDT