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.
>

We could achieve the same effect by emitting gzipped .abw by default.

> *) 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.
>

My in-experience shows here. To me, having a blob of base-64 right in an
XML document makes it much easier to understand the rest of the document.
I'm not sure how splitting an XML document over several files helps me as
the developer of AbiWord.

> *) It's also not clear to me that we want to
> absolutely rule out incremental loading of the PT,

We don't but right now it's not on my radar. If someone else has a burning
passion to do this and will commit to making it work we should revisit for
this reason alone. (If we haven't already decided to go this route.)

> 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.

The issues with RAM usage are almost independent of the PT. The images and
in the PT are stored as PNG. When displayed in AbiWord they're bitmaps.

> 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.
>

I'm not sure this is possible within the framework of AbiWord being a
cross platform application. We really need the full data stored directly
in document.

> 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.
>

We can make a PNG snapshot of any document that can display itself in our
graphics class already. I will write a XP PNG snapshotter as part of the
base class.

I think the statement is overly pessimistic of the possibilities of SVG
snapshots.
You have already written an SVG backend for gnome-print. We can simply ask
any programs that supports gnome-print to print itself to SVG and use
that.

Id a developer is motivated it might also be possible to incorporate a WMF
to SVG convertor to do the same thing on Windows.

> 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.
>

The possibilities of AbiWord-to-the-world bridge plugins are also present.

> 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.

Yes!

> 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.
>

Yes!

> 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.
>

Well I've agreed and disagreed :-)

I'm working on getting the MathML code into the plugin framework now. I'm
mostly a bottom-up developer and I'm discovering issues with the API as I
do the work.

My feeling is that we should evolve our API as we gain experience. If
there are specific short comings you can see with it please let me know.

You know I hold your opinions in the highest regard.

Cheers

Martin

> Best,
> Dom
>
>
>
> __________________________________
> Do you Yahoo!?
> The all-new My Yahoo! - Get yours free!
> http://my.yahoo.com
>
>
>
Received on Fri Jan 14 01:07:40 2005