Re: [dev] Extending the binfilter Module
Hi Ruediger, Rüdiger Timm wrote: 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. as you may know, we _love_ to blow up and to double the amount of code every year, this is one of our favorites, isn't it? :-) Seriously, the goal certainly is _not_ to unnecessarily increase code size. Ideally binfilters would be well formed Uno components, independently build and deployable. To eventually reach this goal, we need to make it independent of the rest of the office. Or let me phrase it the other way, if we are going to keep binfilters dependent on other C++ parts of the office, we could just have kept the original approach, to never change the application cores incompatible wrt to the old binary file format. 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? See above. Keeping binfilter dependent on other C++ code is -a- a maintenance issue, and -b- forbids certain kinds of changes, we want to do. 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. As said above, there are cases where binfilter would hinder the renewal of other code. This is and was the original reason to factor out the binfilters. This is the way we want to go. It was an error in the first place, to ever expose our internal binary formats. binfilters purpose is to correct this error! At least that's my understanding. Please correct me where I am wrong. I tried :-) Rüdiger Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Mathias, Mathias Bauer wrote: 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. I disagree here. Actually the right order is 2,3,4: 3 certainly comes after two, as copying parts of a module is superior to copying the whole module. 4 is after three, as the _goal_ is to make binfilter independent. 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. Certainly. Copying just some pieces is IMHO OK as well. Especially as these pieces are the things which are going to be changed in the non binfilter code, otherwise there wouldn't be any need to copy. Ciao, Mathias Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Heiner, Jens-Heiner Rechtien wrote: Thorsten Behrens wrote: b) move _all_ modules below binfilter into that module, possibly after stripping them to the necessary minimum. Build it once, and tuck it into a safe place (comes close to a, but is smaller integrates with OOo3). Unrealistic, because rebuilding the binfilters might be necessary for all kind of reasons: compiler changes, base line changes, bug fixes, new platforms etc. Over long it would be part of the regular build again, now only bigger than ever before. Good point. We try to stay ABI compatible but fail once a while ... :-( Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Ruediger, Rüdiger Timm wrote: Sorry, now I see your other mails. Looks loke a mail server problem. I saw the mails appearing in reverse order as well, did not expect you to answer sooo fast :-) Rüdiger Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
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]
Re: [dev] Extending the binfilter Module
Armin, Armin Le Grand wrote: I do, but what about the suggestion? Repeating here: 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 am _all_ for it. What's the amount of work left ? Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Armin Le Grand wrote, On 02/07/07 11:40: 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 also prefer making binfilters completely independent from any other OOo code. Constrain is to keep it as small as possible. It might be difficult to duplicate ( or better get rid of) VCL. In theory, only font and output device code should be in use if you can really throw away everything not needed for a filter. For a converter even that should not be needed, because there shouldn't be any layout calculation. But to get all of that done, you need more than one person, or a lot more time than you estimate. And my suggestion would be to start with throwing away all unused code in binfilters, to avoid unnecessary dependencies. This is IMHO not the job for one person alone, but for one person of each application who knows what can be removed. Probably also someone for DrawingEngine code - hey, that IMHO would be you ;) Malte. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Rüdiger, Rüdiger Timm wrote: Armin Le Grand wrote: [...] I haven't read that restriction anywhere. Kays proposal was about any incompatible change below binfilter. It's not a restriction, it's logic. Why else should code be moved to binfilter ATM? Kay is right because incompatible changes below binfilter are a good indication for such cases. See above: i understand Kays recipe as not to do so. And that I consider wrong. That's why I wrote about duplicating code, not just moving it. Duplicating ATM is always a necessity when the original code changes so much that it cannot be used/shared with binfilter anymore. When we would have made it independent, all the necessary code would have been duplicated (most already is), but potential changes would just not need to take notice about binfilter and may be changed in the living modules as required... I do not think that we would save so much. We still would need binfilter on our master workspace just to get part in all changes to linker switches, baseline, and so on. So, everyone doing full builds would still have to check out and build binfilter, it just would be bigger. Of course, costs for adapting and maintaining would vanish. But would that outweigh the initial transformation work? It would. With original plans, binfilter would be a module in the 8.0 release and be link-incompatible from the other modules. It is used as a UNO component anyways, so it would be usable with offices up to today, how incompatible and changed they may ever be (thatÄs the UNO API definition). Think about it: All the compiler changes, environment stuff, includes, incompatible builds, adding to CWSes, would not have happened. This is what i call man-Years and ressources... Rüdiger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Malte and Kay, i will also answer Kay's reply here, he was just asking for the amount of work, too... Malte Timmermann wrote: I also prefer making binfilters completely independent from any other OOo code. Constrain is to keep it as small as possible. It might be difficult to duplicate ( or better get rid of) VCL. Right, it will not be easy. In theory, only font and output device code should be in use if you can really throw away everything not needed for a filter. For a converter even that should not be needed, because there shouldn't be any layout calculation. But to get all of that done, you need more than one person, or a lot more time than you estimate. I do not think so. All estimations can only be guesses, but i would just do a methodical approach: (a) do not link against other C++ modules (b) look at the unresolved externals (c) take one block (c1) check if it's needed at all or the usages may be stripped (c2) reduce to the needed, add to binfilter (d) repeat This will allow the task to be done from someone extern who does not know too much about the modules. We had some ressources for something like that at that time. Maybe there are even 'tricks' someone can use who has deep experience with linking processes. At a minimum approach, it would also be okay to do something like linking binfilter statically against the modules of the release version we keep it at. This may produce something like a binfilterstatic680mi.dll containing all the static linkages without copying any code to binfilter. Maybe we should investigate in that direction, we need someone with experience in that field. Even with the first methodical approach i think a good engineer - with build boxes like Pavel has one - may handle that task in 3-6 months. And my suggestion would be to start with throwing away all unused code in binfilters, to avoid unnecessary dependencies. That's where amout of work was already put and would be goot to put more, but since this is th task You need experienced engineers for, it was seen as expensive, and i agree. This is IMHO not the job for one person alone, but for one person of each application who knows what can be removed. Probably also someone for DrawingEngine code - hey, that IMHO would be you ;) Yes, if we decide to do it that way. I was already commited to do something like that years ago to prevent those man-years of work for others and i am still. We just need to evaluate if there is not a methodical approach which can be handled by someone not deeply involved. If You ask me, this is possible. We just would need ressources to throw on it, and from my point of view they could do it methodically (we need to define that, though) without deep module knowledge. Ongoing changes in the DrawingLayer OTOH REQIRE that knowledge and can not be done methodically from someone else. We just need to weight the costs, real and implied ones... Malte. - 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]
Re: [dev] Extending the binfilter Module
Frank Schönheit - Sun Microsystems Germany wrote: Hi Rüdiger, being late to the thread, and being the one who implicitly initiated this ... Why would you copy additional stuff into binfilter? Because binfilter has a code base which lives several years in the past, whilst the current code base moves forward constantly. At some point, you simply can't stretch this any further. My recent problem was some changes in basic (not basctl), which let the build break in binfilter. There was no reasonable way (I could see) how to adapt this in binfilter: I would have needed to back-port large parts of SFX to BF_SFX (plus probably more), just to be able to use the new basic API. That's certainly nothing I would do, as it bears a completely unknown risk of breakage. We once decided to freeze binfilter, IMO we cannot reasonably expect that it will always be possible to adjust this stone-aged code to the latest and greatest code which has undergone multiple years of additional development. Hi Frank, Thanks for the details. Yes, I totally understand your problem, I think. But, what you did is what I proposed, not what was written here as recipe. You first evaluated to adapt binfilter to the incompatible changes. After spotting all the difficulties you searched for an alternativ. I could live with a rule to try adapting binfilter and, if that prooves to be of unreasonable effort, take importing more code as an (exceptional) alternative. But I am strictly against recommending a code duplication as first choice. Rüdiger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Rüdiger, Thanks for the details. Yes, I totally understand your problem, I think. But, what you did is what I proposed, not what was written here as recipe. You first evaluated to adapt binfilter to the incompatible changes. After spotting all the difficulties you searched for an alternativ. I could live with a rule to try adapting binfilter and, if that prooves to be of unreasonable effort, take importing more code as an (exceptional) alternative. But I am strictly against recommending a code duplication as first choice. Okay, so I think we're on the same track here. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Mathias Bauer [EMAIL PROTECTED] writes: As long as no must changes are due the only disadvantage of binfilter in its current form is that it must be rebuilt sometimes. That's bearable. That reads each time for almost everybody outside Sun. But OTOH, it would prolly only shave off 3 minutes on Pavel's new build machine... ;-) c) have a webservice at services.openoffice.org, that runs OOo2.x, and gets accessed from the sd?-filter of OOo3 Doesn't need to be a Web Service. Could be a standalone converter also. Sure. That was only an example, how to easily maintain the ability to load those documents, and at the same time removing the dead weight of the binfilter component from the install sets. But for the record: I'm perfectly fine with Kay's proposed handling. :-) Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Jens-Heiner Rechtien [EMAIL PROTECTED] writes: Thorsten Behrens wrote: Hm - hard to estimate how many of those binary documents are still in active use. And it would be interesting if they are kept just because of laziness, or for good reasons (I clearly suspect the former). Laziness is a good reason. No one is going over back up tapes just for converting old documents ... as long as it is reasonably safe to assume it's still safe to open the old documents. Active use is a misleading term here. I still want to be able to look into - let's say - old exchanges with the tax authorities but I wouldn't ever want to change these documents. Be able to do that without fiddling around with an old version of OpenOffice.org is a major convenience. Hi Heiner, sure, I see your point. And I'm not against it, in principle. But this whole topic is, in the end, a tradeoff between build time, maintenance effort, download size time, contributor-friendliness, and, of course, how we treat our user base. There will be a point in time when we'll drop support for our legacy file formats, just like MS dropped support for 16bit applications. It's not a question of 'if', it's a question of 'when'. And as a developer, I tend to favor the 'earlier', rather than 'later' scheme - because it frees us to focus on the issues that affect large fractions of our user base, rather than minorities... ;-) Before we drop our own legacy filters (which would be a major inconvenience for lazy long time office users) we should think hard about obsolete 3rd party filters which could be removed without alienating our own user base. Sure. b) move _all_ modules below binfilter into that module, possibly after stripping them to the necessary minimum. Build it once, and tuck it into a safe place (comes close to a, but is smaller integrates with OOo3). Unrealistic, because rebuilding the binfilters might be necessary for all kind of reasons: compiler changes, base line changes, bug fixes, new platforms etc. Over long it would be part of the regular build again, now only bigger than ever before. Well, only if it is an in-process component. Mathias already mentioned the stand-alone converter idea... Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Rüdiger, being late to the thread, and being the one who implicitly initiated this ... Why would you copy additional stuff into binfilter? Because binfilter has a code base which lives several years in the past, whilst the current code base moves forward constantly. At some point, you simply can't stretch this any further. My recent problem was some changes in basic (not basctl), which let the build break in binfilter. There was no reasonable way (I could see) how to adapt this in binfilter: I would have needed to back-port large parts of SFX to BF_SFX (plus probably more), just to be able to use the new basic API. That's certainly nothing I would do, as it bears a completely unknown risk of breakage. We once decided to freeze binfilter, IMO we cannot reasonably expect that it will always be possible to adjust this stone-aged code to the latest and greatest code which has undergone multiple years of additional development. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Extending the binfilter Module
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Kay, Kay Ramme - Sun Germany - Hamburg schrieb: 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 wholeheartedly agree with your recipe. Perhaps we should emphasize that people should really try hard to use the first recommendation even if this might take some time. It has the big benefit of making binfilter smaller and avoiding future dependencies in this module. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
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. Rüdiger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
On 2.2.2007, at 14:11, Rüdiger Timm wrote: 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. What about making binfilter SO only module? ;-) -- Pavel Janík - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
On Fri, 2007-02-02 at 14:18 +0100, Pavel Janík wrote: What about making binfilter SO only module? ;-) -1 Unfortunately .sdw etc documents exist and are a fact of life, we do still need to import them. e.g. my performance review still comes in .sdw format, we wouldn't want to drop importing that :-) The binfilter just needs to be reduced even further. Here's a list of some potential candidate methods for removal :-) http://people.redhat.com/caolanm/callcatcher/m201.binfilter.log C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
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 important but also important is avoiding to burn development resources for maintaining code you don't want to touch anymore. 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. 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. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Thorsten Behrens schrieb: There are at least three possible ways to do this gracefully: a) drop binfilter for the next major release, telling users to convert their documents using OOo2.x. Can even implement a tiny filter replacement, that says so in a message box. IMHO OOo3.0 would be too early for this. I think we could drop the export but the necessary work to remove only the exporter is just too much. b) move _all_ modules below binfilter into that module, possibly after stripping them to the necessary minimum. Build it once, and tuck it into a safe place (comes close to a, but is smaller integrates with OOo3). Following Kay's proposal that's what you get if you always chose option 2 or 3. This would do it not for all modules in one step but for each of them on demand. I think that's the better approach. Yes, moving all the modules in one step wouldn't take much time, but stripping them could be expensive. Why moving code to binfilter without a need? As long as the binfilter module still runs well with the built-in VCL and no must changes from VCL must be done in binfilter - why not saving the time and wait? Before the problem with basctl came up we didn't talk about the other modules below binfilter. Why should we do it now? As long as no must changes are due the only disadvantage of binfilter in its current form is that it must be rebuilt sometimes. That's bearable. c) have a webservice at services.openoffice.org, that runs OOo2.x, and gets accessed from the sd?-filter of OOo3 Doesn't need to be a Web Service. Could be a standalone converter also. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Thorsten Behrens wrote: Caolan McNamara [EMAIL PROTECTED] writes: On Fri, 2007-02-02 at 14:18 +0100, Pavel Janík wrote: What about making binfilter SO only module? ;-) -1 Unfortunately .sdw etc documents exist and are a fact of life, we do still need to import them. e.g. my performance review still comes in .sdw format, we wouldn't want to drop importing that :-) Hm - hard to estimate how many of those binary documents are still in active use. And it would be interesting if they are kept just because of laziness, or for good reasons (I clearly suspect the former). At any rate, binfilter is a huge, tangled mess (yes, more so than the average OOo module), and maintaining/building/shipping it benefits only those tiny fraction of users with sd?-documents. *If* we want to start reducing build time/reduce developer load/free resources for other tasks, then reducing code size is clearly top on the list - and binfilter would be a huge blob we could drop in one go. I do not see your point here. There is a configure option to leave out binfilter from a build. For an average OOo developer or even someone building OOo for his own use that is a good option. Only those people building for official distributions have to care about that module. There are at least three possible ways to do this gracefully: a) drop binfilter for the next major release, telling users to convert their documents using OOo2.x. Can even implement a tiny filter replacement, that says so in a message box. Would be a clean solution, though not my preferred one. b) move _all_ modules below binfilter into that module, possibly after stripping them to the necessary minimum. Build it once, and tuck it into a safe place (comes close to a, but is smaller integrates with OOo3). And you are sure that it always integrates with OOo? I suspect that we would buy in a lot of problems and technical effort to keep that running . c) have a webservice at services.openoffice.org, that runs OOo2.x, and gets accessed from the sd?-filter of OOo3 Can you imagine f.e. debian to use such an approach? :-) Rüdiger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Thorsten Behrens wrote: Caolan McNamara [EMAIL PROTECTED] writes: On Fri, 2007-02-02 at 14:18 +0100, Pavel Janík wrote: What about making binfilter SO only module? ;-) -1 Unfortunately .sdw etc documents exist and are a fact of life, we do still need to import them. e.g. my performance review still comes in .sdw format, we wouldn't want to drop importing that :-) Hm - hard to estimate how many of those binary documents are still in active use. And it would be interesting if they are kept just because of laziness, or for good reasons (I clearly suspect the former). Laziness is a good reason. No one is going over back up tapes just for converting old documents ... as long as it is reasonably safe to assume it's still safe to open the old documents. Active use is a misleading term here. I still want to be able to look into - let's say - old exchanges with the tax authorities but I wouldn't ever want to change these documents. Be able to do that without fiddling around with an old version of OpenOffice.org is a major convenience. At any rate, binfilter is a huge, tangled mess (yes, more so than the average OOo module), and maintaining/building/shipping it benefits only those tiny fraction of users with sd?-documents. *If* we want to start reducing build time/reduce developer load/free resources for other tasks, then reducing code size is clearly top on the list - and binfilter would be a huge blob we could drop in one go. There are at least three possible ways to do this gracefully: a) drop binfilter for the next major release, telling users to convert their documents using OOo2.x. Can even implement a tiny filter replacement, that says so in a message box. Before we drop our own legacy filters (which would be a major inconvenience for lazy long time office users) we should think hard about obsolete 3rd party filters which could be removed without alienating our own user base. b) move _all_ modules below binfilter into that module, possibly after stripping them to the necessary minimum. Build it once, and tuck it into a safe place (comes close to a, but is smaller integrates with OOo3). Unrealistic, because rebuilding the binfilters might be necessary for all kind of reasons: compiler changes, base line changes, bug fixes, new platforms etc. Over long it would be part of the regular build again, now only bigger than ever before. c) have a webservice at services.openoffice.org, that runs OOo2.x, and gets accessed from the sd?-filter of OOo3 A webservice for confidential documents? Not a good idea ... Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Rüdiger Timm schrieb: binfilter isn't static. During the last months even more code has been moved from f.e. sw into binfilter. Yes. Because we discovered even more filters we don't want to maintain anymore. :-) 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). Agreed. Perhaps we should give all three options the same priority and make it clear that it is an individual decision based on trade-off considerations. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
