Re: Generic Embeddable plugins.

Le jeudi 13 janvier 2005 à 05:47 -0800, Dom Lachowicz a écrit :
> Hi Martin,
>
> > > Something possibly worth examining is using a
> > > structured document format, such as OOo does, in
> > which
> > > embedded objects (including things like PNG/JPEG
> > > pictures) are stored in their own "stream".
> > >
> >
> > I think that the only benefit of this is that you
> > can incrementally load
> > your document as the PieceTable is populated since
> > you can access the data
> > items (images and embedded content) as they're
> > needed.
>
> Other benefits include:
>
> *) Not bloating the file's size. Base64 will expand
> the objects' size significantly.
>
> *) Not using a hack to embed something non-XMLish into
> an XML file. There's something to be said for keeping
> the embedded components physically and logically
> separated from the main document.
>
> *) It's also not clear to me that we want to
> absolutely rule out incremental loading of the PT,
> especially wrt potentially large embedded objects such
> as images, XL spreadsheets, etc. Abi has problems with
> big data now (especially wrt RAM usage), and you've
> suggested "more of the same", which seems
> less-than-ideal. If it were possible to lazy-load
> these objects, we'd might be able to load them
> on-demand, and passivate the objects out of memory
> when they're not in use.
>
> These problems become greatly compounded when you
> advocate embedding:
>
> 1) A PNG/JPEG of the embedded $FOO
> 2) A SVG of the embedded $FOO
> 3) The embedded $FOO itself
>
> I believe this to be overly optimistic. I know of 2
> apps that can do this - Sodipodi/Inkscape (a SVG
> editor) and Dia (a Visio clone). It's unlikely that
> we'll see many more apps doing this in the future,
> save maybe Gnumeric. So we've limited our plugin
> system's usefulness to maybe 5 apps out of the box,
> which are all heavily Unix-centric.
>
> I don't believe that we'll see a lot of buy-in, and
> this ultimately will hurt our users. The world does
> not need another embedded plugin API from some niche
> app. We'll never grow like this.
>
> I believe that it may well be the best idea to
> evaluate other component embedding systems (such as
> Netscape's, amongst others) and perhaps adopt one of
> them or - at a minimum - create a bridge to these
> APIs. By doing so, we get instant buy-in from a wide
> variety of vendors, plus significant inertia. MSIE,
> Konq, and Opera did it with Netscape's plugin API.
> Maybe we need to do something like this too.
>
> A structured format is not without its own drawbacks,
> of course. As is using someone else's plugin API. I
> happen to think that their benefits far outweigh the
> drawbacks. Feel free to disagree.
>
> Best,
> Dom

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.

Best regards,

Jean
Received on Thu Jan 13 18:31:14 2005