Re: Generic Embeddable plugins.

From: Jean Bréfort <jean.brefort_at_normalesup.org>
Date: Thu Jan 13 2005 - 22:13:09 CET

Le jeudi 13 janvier 2005 à 10:17 -0800, Dom Lachowicz a écrit :
> --- Jean Brfort <jean.brefort@normalesup.org> wrote:
>
> > After some more thoughts, my opinion is that
> > netscape plugin api is not
> > what we need. It is devised for display files, not
> > edit them, so you
> > cannot save modifications in a plugin contents. The
> > only possible
> > interaction from a plugin to netscape is javascript
> > calls.
> > There are some enums in the headers that make think
> > other possibilities
> > were envisioned at some moment, but they are not
> > documented and
> > apparently not implemented either (I made tests to
> > negotiate objects
> > size from inside the plugin when working on
> > mozilla-bonobo and the calls
> > never returned).
> > Gnome has a mostly working component system: bonobo.
> > Printing is missing
> > at the moment, but I feel it would not be very
> > difficult to write an
> > appropriate interface.
>
> If by "mostly working" you mean "all of the Gnome
> developers are avoiding it like the plague", then yes,
> it is "mostly working." Bonobo doesn't begin to
> address any cross-platform considerations we might
> have. I, for one, would not want to make a CORBA ORB
> part of AbiWord's requirements. Nevermind the fact
> that Bonobo is built around GTK+, which we only use on
> our Unix platform...
>
> That's not to say that things like COM, Uno, XPCOM,
> and Netscape don't all have their own set of
> deficiencies. They all have major advantages and
> drawbacks.
>
> I'm not advocating any particular solution at this
> point in time. I'm only advocating that those who
> would design and implement such a feature look before
> they leap.
>
> Contrary to Jean's assertion, Netscape plugins can
> send streams of data back to the browser. What is
> lacking is a standard way for the browser to *request*
> that it be given a stream of data from the plugin.
>
> The Netscape plugin API will also work nicely with our
> existing GR_Graphics classes when printing. Some small
> modifications will be necessary, but nothing major.
> For contrast, Bonobo's printing interface was declared
> dead and unmaintained several years ago.
>
> For reference:
>
> http://web.archive.org/web/20040203041440/http://devedge.netscape.com/library/manuals/2002/plugin/1.0/
> http://www.mozilla.org/projects/xpcom/
> http://udk.openoffice.org/
>
> What we have to find is the right combination of:
>
> *) Ease of design/implementing said plugin
> architecture
> *) Ease of creating new plugins
> *) Market for vendor buy-in, 3rd-party plugins
> *) Usefulness to our users
>
> If we can't implement it, it's useless. If our users
> won't want to use it, it's useless. If people won't
> want to write plugins for it or if people can't find
> plugins for it, it's useless.
>
> Best,
> Dom

OK, I'm probably wrong. I stop now. If I can do something for abi, tell
me. It should be simple because I am not very familiar with the code at
the moment.

Best regards,

Jean
Received on Thu Jan 13 22:11:12 2005

This archive was generated by hypermail 2.1.8 : Thu Jan 13 2005 - 22:11:13 CET