On 11/21/08 18:01, Michael Meeks wrote:
That sounds great; just to give a quick rational as to why this approach. While clearly a separate UNO component, or things living in oox is the end-goal, I'm a fan of step-wise re-factoring - such that we can prove that nothing broke during the process, and such that there is only one copy of the code to maintain and develop at any time.My hope is that by adding OOX export here, then going on to re-factor the existing combined filter to use the UNO interfaces to build it's model, we can incrementally move to the point that chipping that whole export chunk off into it's own component (or into oox) becomes easy - while still being to prove that nothing broke. That way, hopefully we get where we want to go, while keeping everything working in the meantime; that is the thinking anyway - does it make sense ?
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.
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.
Of course, the way to avoid such situations in the future is to discuss these things before starting the implementation.
Niklas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
