From: Dom Lachowicz (domlachowicz@yahoo.com)
Date: Wed Oct 22 2003 - 11:08:06 EDT
Hi Jeremy,
> Our core can be just as clean without them being a
> plugin, for
> example consider the work for incorporating the
> importer/exporters
> on platforms that do not support plugins. If an
> importer/exporter
> is required to complete a build, it is required,
> having it split
> into an executable and shared object makes little
> difference than
> being in a single executable if the code is nearly
> identical and
> the dependencies are the same. [Yes in theory,
> having part of
> the code in a shared object does allow for upgrades,
> but at the
> moment we only release plugins at the same time as
> we release
> complete builds, and many updates to our plugins are
> to take
> advantage of, or changes because of, features
> added/changed in the
> rest of our code, so that argument does not yet
> apply. Arguably,
> until we have a stable importer/exporter ABI, it
> simplifies
> matters to have a monolithic build.]
I think the idea here is to represent several types of
builds for our different types of users:
1) Minimalist, streamlined build
2) "User-friendly build"
3) "Everything, plus the kitchen sink" build
Now, having such things as JPEG and WMF as plugins
allow us to serve all three purposes. It keeps our
code honest; it keeps our design clean; it helps abi
be more modular. In theory, it lets Abi integrate
better with the user's OS by not forcing any one
solution down your throats, nor does it preclude one
from looking at the problem from more than one
perspective.
The "monolithic plugin" work that FJF did was
interesting. It works around several problems - yet
the major one has since been fixed (newer
compilers/linkers on QNX support dynamic loading of
C++ code. Our 2.0.1 release on QNX supports plugins).
My gut feeling is that the API/ABI of Abi's innards
(at least those APIs consumed by plugins) will likely
largely stay static for the STABLE series - if the
changes between 2.0 and 2.0.1 are a good indicator,
which I think they are.
If you'd like, we can set up policy for API/ABI
freezing for the STABLE series and/or we can take
strides to make sure that API/ABI issues are less
likely to happen (struct padding, implementation
hiding, etc...)
Also, we could start up work on a better C/C++ API for
plugins intended to minimize these sorts of issues.
Note that this work won't happen in STABLE, so it's
worth talking about in a different thread, but it is a
moot point given this thread's context.
I've set up what #1 means, and I don't think that it's
up for discussion now. #3's meaning is obvious to the
point of banality. Let's focus on what happens in #2,
and how to best solve it for our individual platforms,
while keeping in mind that #1 and #3 won't be
changing.
Best regards,
Dom
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
This archive was generated by hypermail 2.1.4 : Wed Oct 22 2003 - 11:09:01 EDT