Mathias Bauer wrote:
Rüdiger Timm schrieb:
Kay Ramme - Sun Germany - Hamburg wrote:
FYI
Matthias Huetsch, Malte Timmermann, Michael Brauer and I recently had a
discussions regarding how to deal with binfilter in case of incompatible
changes of modules used by binfilter.
We came up with the following recipe: For every request of an additional
module for / change of binfilter the following steps are to be tried in
the following order:
1. Check if the dependency could not be removed / avoided completely.
- For the above change this means, to verify that basctl is indeed
needed for loading / storing documents.
2. Copy the code which is needed only. - For the above change this
means, that the serializers (import / export) may just be copied out of
basctl to binfilter (respectively they may be just reimplemented if this
is easier :-) .
3. Copy the whole module. - If the target module is reasonable small,
the whole module may be copied to binfilter. For the above change this
would mean to copy basctl to binfilter.
4. Adapt binfilter to the incompatible changes done in the dependent
module. - For the above change this would mean, to adapt binfilter to
the changes done in basctl.
5. Do not change the dependent module incompatible. - For the above
change this would mean, not to change basctl incompatible.
I created a module page for the binfilter module in the OOo wiki and
copied the receipt to this page as well:
http://wiki.services.openoffice.org/wiki/Framework/Modules/binfilter
Hope that helps
Kay
That's a joke, isn't it?
From my point of view of course it has to be (according to your numeration)
1.
4.
5.
2.
3.
Why would you copy additional stuff into binfilter? We did enormous
efforts to get that monster stripped, and you plan to blow it up again.
Why? If someone does incompatible changes he must do all necessary
adaptions in modules above. Regardless of the name of those modules. Why
change code in 'sw' but leave 'binfilter/bf_sw' untouched?
OK, there may be rare cases where no one is able to adapt stone aged
binfilter code with reasonable effort. But that is an evidence of
incapacity and should be the strict exception.
At least that's my understanding. Please correct me where I am wrong.
IMHO you have a somewhat constricted perspective. Build times are
May be. Of course what i wrote are just my personal thougths and
feelings. And I didn't want to offend anyone.
important but also important is avoiding to burn development resources
for maintaining code you don't want to touch anymore.
binfilter isn't static. During the last months even more code has been
moved from f.e. sw into binfilter.
I think the problem is that you can't give a fixed order for 2,3 and 4.
This must be checked for every single case. Perhaps Kay should point
this out in the wiki.
OK, accepted. But from my point of view we should not make 'move more
basic code into binfilter' (2 or 3) a default before 'adapt binfilter to
the changes' (4). I even doubt that (4) in general is more effort than (3).
But IMHO it's clear that option 1 is by far the best and should be aimed
for as often as possible and that option 5 should be considered only in
desperate cases.
Rüdiger
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
