From: Alan Horkan (horkana@tcd.ie)
Date: Sun Jul 28 2002 - 22:14:51 EDT
on a vaugely related matter has any thought been given to a consistant
plugin api across Gnome-Office? specifically is Abiword trying to copy
anyone or are we hoping someone will copy our pluing API.
For basic text processing type plugins (like change case, word count or
something) in theory some plugins could be reusable across many
applications (i just described a library didn't i, ho hum).
Comments?
Sincerely
Alan Horkan
On Tue, 16 Jul 2002, Kenneth J.Davis wrote:
> Date: Tue, 16 Jul 2002 04:12:31 -0400
> From: Kenneth J.Davis <jeremyd@computer.org>
> To: abiword-dev@abisource.com
> Subject: Re: commit: abi & abiword-plugins: simple plugin interface
>
> Andrew Dunbar <hippietrail@yahoo.com> 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.
> >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
> jeremyd@computer.org
>
This archive was generated by hypermail 2.1.4 : Sun Jul 28 2002 - 22:22:27 EDT