Do you really think that it's worth the effort? so3 is only used inside of
binfilter and could be easily packaged in a way that it is installed only if
binfilter is installed. The so3 library is only a few 100KB large and that
doesn't make a big difference in the whole binfilter package, even if you saved
~100 KB from it (and I doubt that you will reach that).

So perhaps there's bigger fish to catch?!

Well - if somebody would have removed those dead code in the beginning, when he
noticed that its not needed anymore (except in binfilter), then we would *not*
ship 2.3 with the crash described in ìssue 81299, as we do now. Also, pl would
not have invested the (failed) effort into changing the ResId calls in the module.

Both cases - wrongly using code from that module, and investing effort (better
spent otherwise) for APi changes - could happen again. Yes, I think it actually
*is* worth the effort.

Honestly, I am surprised somebody could question this. It's also a matter of
code quality, maintenance costs, and what other more buzzwords you can think of
- isn't it?

btw: the first step, where I stripped the most obvious dead code only (instances
with the broken usage of the res manager) reduced the library size from 638284
to 549348 (unxlngi6.pro). Hmm, I actually think 100K are possible :-P

Instead of so3 I would recommend to invest your time in other parts of binfilter
(e.g. forms etc.) where the gain would be much bigger. This is waiting for a
brave developer for quite a long time.

> This is waiting for a brave developer for quite a long time.

Which is new to me. If you elaborate, I might think about it.

Other than that: If we moved the complete so3 to binfilter/bf_so3, that would be
fine with me, too (In fact, I think about doing so with the remaints once I did
a reasonable amount of removal).

Really, I don't care (at the moment) how big binfilter libs get. What I do care
is that we have smelling, not-working code where only a few adepts know we
shouldn't use it. Because of this "there's bigger fish than this to
catch"-atttitude, we ship 2.3 with a crash in Base. I will make sure this won't
happen again (at least not because of so3 :).

and for the said "much bigger gain" in binfilter ... There are different
opinions on how long we continue to ship the binary filters, so I am not yet
sure any effort is well-spent there.

The problem is when people use code without asking its owner (if someone used
so3 without asking me or mav that would be the case) or when people make big
changes like the ResMgr change without really having a strategy to find all the
pitfalls and without a comprehensive testing. 

There is no difference between so3 and binfilter. Both are modules only used to
load and save old binary files. As you write you don't care about the size of
binfilter I don't know why you care for the size of so3. 

I agree that it is questionable if investing time in binfilter is worth the
effort. But it's perhaps even more worth it than doing something in so3 as the
amount of superfluous code is bigger in binfilter than in so3. 

I don't know why base crashes due to problems in so3. I wonder why base uses so3
at all. Perhaps we should follow up on this elsewhere.

Can we decide to simply move so3 to binfilter? And can we change the summary
accordingly?

Sure

done in CWS so3de3adcorpses

developer task -> VERIFIED myself (so3 is empty in my CWS after an "cvs update
-d -P")

now really setting to VERIFIED

This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues