Re: Generic Embeddable plugins.

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

                
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
 
Received on Thu Jan 13 14:48:45 2005