Subject: Re: libole2
From: James Montgomerie (jamie@montgomerie.net)
Date: Tue Jun 06 2000 - 16:12:20 CDT
Quoting "Eric W. Sink" <eric@sourcegear.com>:
> OK, now I'm just really curious:
>
> Could someone explain what the purpose of the recent
libole2 code
> changes was?
The purpose was to enable the beginning of the Word
exporter. The original plan was to extend wv to write
Word files as well as read. This would have been
extremely complicated. LibOLE2 contains mechanisims for
writing OLE files - it's used by Gnumeric to write Excel
files - and it seemed like a much better idea to use
this already developed code than to try to develop some
of our own.
LibOLE2 is also being very actively maintained, and it's
addition to wv gives wv a more robust, cleaner OLE
stream decoding mechanisim, which should leave us with a
better Word importer, and one that's will in some cases
be easier to debug.
> I saw this code change pending. I saw what appeared
to be a great
> deal of consensus that it should be committed, from
several people
> here on the list who are more active than I. So, I
assumed there was
> a reason for the change of which I was simply unaware.
>
> Then I saw some discussion about this code causing a
huge slowdown in
> the Word importer, and yet the consensus for a commit
still appeared
> quite strong.
I'd /really/ be surprised if it caused a huge slowdown.
I'm not looking at the code here, but from memory, the
only measurable overhead on the wv side would be, at
most, one extra conditional and one dereference per
character read. Even with huge files I don't think
that'll be noticable.
I could do some profiling of the importer over the
weekend to see if the slowdown really exists, and if it
does, where it lies.
[As an aside, as we discussed earlier, Word importing
will take a long time on a debug build, because wv does
output a /lot/ of debug data.]
> Now, this particular fragment of code is irking me,
because it
> completely breaks the Windows build, so I'm wondering
about its
> purpose.
>
> Am I missing something? :-)
>
> For the record, this code appears to simply not even
compile under
> Windows. I suspect that it was never compiled under
Win32 before it
> was checked in.
>
> The current build problem is the non-presence of
> mode_t on that platform, but we are likely to
encounter other problem
> before this code gets back to the functionality we had
before.
>
> Last week, our Word importer worked. Now it does not.
What did we
> gain, and how can we recover our losses?
I thought the new code had been tested on Windows by
other on the list, but it appears that it had not been.
However, do not be to disheartened - the old wv code and
the glib port are known to work on Windows, the only
thing which is not working is LibOLE. It's a well
written peice of code, and I am sure that, even if
mode_t is not our only proble, the other problems will
be just as small. Our word importer will work again
soon, and it will be better than it was before!
To answer 'what have we gained', the primary gain is the
ability to more easily write a word exporter (the
original purpose of the merge), but we have also gained
the knowledge (and the goodwill :-) of the LibOLE
maintainers, and (soon) a more robust word importer.
Jamie.
-----------------------------------------------------
This mail sent through IMP: http://web.horde.org/imp/
This archive was generated by hypermail 2b25 : Tue Jun 06 2000 - 16:12:16 CDT