Re: Plugin RFC

> 1) Ship a set of useful, fairly polished plugins
> and

agreed++

> 2) Statically link that set in. Other plugins could still be shipped
> in an "abiword plugins" package, and modularly loaded at runtime

For fedora, I already include all (useful) already in 1 package. At the
moment I include them all as a shared lib, but statically building them
wouldn't really make a difference to any end-user.

> We would need to define that set (or at least criteria for what counts
> as "useful" and "polished"). Something like ODF would probably count.
> Something like AbiGimp
> probably doesn't count.

I was wondering how 'our' PortableApps version is created now. Do they
take our binary, or do they compile it themselves. If they just take our
version, then there might still be some interest in shipping a very
light version as well (ie, like we currently do it).

> A down-side of this is that the executable's size would be larger -
> (roughly) sizeof(abiword.exe) + sum(sizeof(each_plugin)). However,
> we're talking

For an end user, it won't matter at all where the size is located
really.

> Startup of Abi 2.6 on Windows is significantly slower than it used to
> be. Wildly guessing, I think that this is due to some of our new
> external dependencies and also to plugin loading.

For non-en_US locales, I see a definite speed improvement though.

> Another benefit of this *may* be that we won't run into those "plugin
> conflict" problems on Windows, where we can't load both plugin A and
> plugin B at the same time. Again, this is speculation.

I'd rather see the issue properly analyzed, instead of "hoping it gets
away after some random changes".

 Marc
Received on Thu Apr 10 18:29:42 2008