Hi Niklas,
On Fri, 2008-11-21 at 18:45 +0100, Niklas Nebel wrote:
> The problem is, we have spent a lot of effort already to keep the
> filter implementation in oox separate from the application (new APIs
> and all), and this is something that this change would break.
Fair point.
> Everybody is asking for modularization, and I don't want to discard
> all this effort and take a step backward now, with the hope of fixing
> it some time later. Even start-up performance might be affected, if
> oox is added as a dependency to sc. So, at the risk of seeing more
> "evil Sun isn't accepting our contributions" blog entries: No,
> ooxml02 can't be integrated as-is.
Heh ;-) Well - rejecting code for a good technical reason like this is
normal & fair enough, and I'm glad to see that as your main objection.
Hopefully you'll be pleased to hear that we're working to overcome it. I
am still convinced that an incremental solution towards modularisation &
UNO interfaces is the right approach, but hopefully this meets your
concerns too; and at least exceeds the test of "is no worse".
I just committed a chunk of code to the ooxml02 CWS. This extends the
visibility markup to the classes we use during import and export: which
turned out to be fewer symbols than I had feared (10k vs. 9k symbols),
and splits out all of the calc filters (except for xml) into a separate
library: 'scfilt' which is demand loaded via an abstract interface.
While it works nicely on Linux, I need to do some work on
Win32 to defeat the different set of compiler quirks ironed out there;
that work is pending. Here are the results:
Before:
libscli.so 8.2Mb
After:
libscli.so 6.8Mb - a ~1.4Mb saving (15%+ of libscli)
libscfiltli.so 1.8Mb
Of course, if we go using the filters, we loose, but clearly
for the common ODF and startup cases we win substantially, and the
extra size can be clawed back as we migrate the existing export
filters to use pure UNO interfaces, and privatise the symbols again.
So - no startup performance problem - instead should be an improvement,
no step backwards - the filter code is broadly un-changed, and no new
dependency for the calc core. We also lost three previously global
headers into source/filter/inc, and can now at least run and not crash
without scfilt and any Excel/RTF/Lotus/qpro/etc. import/export (though
not the world's most useful feature to be sure).
In addition - I noticed & fixed a number of problem
symbols. The CWS tune03 seems (some time ago) to have publicly exposed a
number of things without Sc prefixing that could be problematic in
future: eg. 'Collection' 'StrCollection'. I added an Sc prefix to:
ColToAlpha, Collection, SortedCollection, StrCollection,
TypedStrCollection, AutoFmtPreview, DataObject and SingleRefData -
hopefully that will avoid symbol clash problems in future.
Having said that, there is no real symbol clashing either before or
after the changes according to my interposing tooling (modulo something
completely unrelated that thb just fixed in basegfx), so this looks
safe.
So; a smaller calc core, with an incremental path to
re-factoring the filters ?
HTH,
Michael.
[1] -
http://sc.openoffice.org/source/browse/sc/sc/inc/collect.hxx?r1=1.2&r2=1.2.52.1&only_with_tag=cws_src680_tune03
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
