Hi Kay,
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.
I am still wondering why nobody invited me to this discussion as i
surely would have been able to add some background and initial thoughts
to the whole theme. Anyways, i am pretty happy with the direction it is
taking.
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.
That's the right way to go.
Please take in mind what kind of code is/will be moved to binfilter:
- code that is no longer used in the 'living' office modules, but needed
by the old binary filter mechanisms
- code that is completely rearranged and cannot be adapted to also keep
up the needed (C++) APIs and functionalities for binfilter
Both cases happen, BECAUSE binfilter allows us to do things like that at
all and to enhance the 'living' office modules, not to expand binfilter.
The expansion of binfilter is the price to pay to keep the old binary
filters running, and that price was intended and is accepted ATM.
Do not forget that it is even DANGEROUS to change functionality/code
without noticing that binfilter is still using it. Binfilter may well
need controlled fixes from time to time in shared code regions which may
also enhance the living modules, but the other way around You risk to
break binfilter functionality which cannot/is rarely tested anymore.
That's (one of the reasons, there were many others) why my initial plan
always was to freeze binfilter on a defined state.
Defined state means: Let it rest on a published version, this is never
deleted and stays buildable (if fixes are needed).
Freeze means: Add all still missing and urgently necessary C++
dependencies methodically: Link without the standard modules and add
missing code. Yes, this might take a while and is not easy but might
have been done by one person methodically, not costing man-years of
bandwidth, service, maintaining, bulding, adapting, developer time, ...
With the suggested steps we move to that target, so i am happy about them.
Comparing the costs spent up to now by all and that will be spent until
the goal is reached, i again have to suggest (as years ago) to do it
once, by one person and for the next public release. The resulting
binfilter module will be an UNO-API only module, independent of 'living'
C++ code and can then rest on that version.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
