Re: Generic Embeddable plugins, Take 2

Hi Marc,

J.M. Maurer wrote:
> After reading the whole Embedding thread, I think 'we' are confusing
> some things.
>
> 1) The way martin plans to implement the Math plugin is *not* embedding
> components. Martin's proposed API combined with a C api for the rest of
> AbiWord presents a nice framework for future abiword plugins to use. It
> would allow them to tightly integrate with AbiWord (such as the math
> plugin) using a stable API (unlike we have now).
>
> 2) The embedding issue is a totally different problem. Embeddable
> components would (generally speaking) not use anything from Abi such as
> the Graphics classes, at all. Furthermore they will be running most
> likely totally out of process. This means those embedded components will
> NOT be tightly integrated with AbiWord. This is a feature, not a bug. If
> you want really tight integrated plugins, use 1).
>

I actualy do not see real difference between the two. What Martin is
proposing is embeded content, which is generated by a server that just
happens to be AW plugin and makes use of AW internals. The other is
embeded content generated by server that has no formal connection with
AW. The former is clearly just a special case of the latter, and it
seems to me that making a distinction between the two is
contraproductive, leading to two sets of API that achieve excatly the
same thing.

I see no reason why the MathML plugin could not interface with AW in
exactly the same as the as a generic embeded server would: we tell it
this is your area of the document to draw into and it does so. Whether
it uses our graphics class to do this, etc., is none of our business.

More I think about this, the less I am happy about having to accomodate
the layout classes to this specific problem, notably the creation of the
  fp_MathRun; it is not a generic solution to what is a generic problem.
Even if the fp_MathRun is moved inside a plugin directory, it will still
have to be added to the enum in fp_Run.

There should be fp_EmbeddedContentRun class, providing generic inteface
to the embedded server, and an architecture that would allow the server
to connect to this interface. In the Math case, Martin can have
fp_MathRun derrived from fp_EmbeddedContentRun, but AW would be
oblivious to that, it would just be manipulating fp_EmbeddedContentRun;
a code that would allow for ActiveX to be embedded would have its own
derrived class, etc.

The physical location and size of the fp_EmbeddedContentRun should be
controlled by AW alone, not by the server; we give the server a space to
work with. What the sever does within this space and how it does it is
entirely up to it.

Tomas
Received on Mon Jan 17 10:45:46 2005