On 15.06.2011 04:36, Greg Stein wrote:
On Tue, Jun 14, 2011 at 21:50, Pedro Giffuni<[email protected]> wrote:
...
But some of that stuff is actually bloatware. I think libwpd, libwps
and libwpg are basically in the same boat as binfilter: the
functionality shall me made optional as external modules in the
By moving these importers over to *optional* extensions, then we can
do several things:
1) simplify the initial build and dependencies, moving us towards a
buildable and useful package
2) add the functionality back in over time as developers' interest focuses on it
3) retaining the optional status allows linking to LGPL and similar
weak-copyleft libraries
Correct me if I'm wrong, but my understanding was that nowhere in the
code repository we can have code that links against LGPL code. And of
course extensions are part of our code base also.
This goes back to a question that I had before: can file importers fit
into OOo's extension system?
<radio Erewan>"In principle yes, but..."</radio Erewan>
Here's the "but": "real" extensions must use stable APIs based on UNO
when the call into OOo and they also must export all their functionality
through such APIs.
Some filters do it this way, some don't. So some may become extensions,
some can't. Usually it is quite some work to do to get filter code into
a state that allows to use the filter as an extension. Must be checked
for each filter individually.
But due to my considerations from above I assume that this doesn't help
us with LGPL code, right?
BTW: none of our current filters has code not (co-)owned by Oracle,
IIRC, so all existing filters could be made available under the ASL.
Regards,
Mathias
