Re: Generic Embeddable plugins.

--- Jean Bréfort <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

                
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
Received on Thu Jan 13 19:18:46 2005