From: Kenneth J.Davis (email@example.com)
Date: Tue Jul 16 2002 - 04:12:31 EDT
Andrew Dunbar <firstname.lastname@example.org> wrote on 7/16/2002 3:41:30 AM:
>--- F J Franklin <F.J.Franklin@sheffield.ac.uk>
>wrote: > > I really don't think we want to do this.
>> 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 , but
the plugin does not call directly into AbiWord, it
instead goes through a C->C++ mapping API, where
AbiCapi impliments a C interface  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.
 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.
 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
>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.
>> >> 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
This archive was generated by hypermail 2.1.4 : Tue Jul 16 2002 - 04:58:46 EDT