incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Bauer <Mathias_Ba...@gmx.net>
Subject Re: External dependencies (was Re: [discuss] remove of binfilter module)
Date Wed, 15 Jun 2011 08:59:12 GMT
On 15.06.2011 04:36, Greg Stein wrote:
> On Tue, Jun 14, 2011 at 21:50, Pedro Giffuni<giffunip@tutopia.com>  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

Mime
View raw message