Andrew Dunbar <[EMAIL PROTECTED]> wrote on 7/16/2002 3:41:30 AM: > >--- F J Franklin <[EMAIL PROTECTED]> >wrote: > > I really don't think we want to do this. >I've >> 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 AbiCapi. :-) Jeremy Davis [EMAIL PROTECTED]
