Subject: Re: libole2
From: Paul Rohr (paul@abisource.com)
Date: Thu Mar 30 2000 - 17:56:35 CST
At 12:00 AM 3/31/00 BST, James Montgomerie wrote:
>The big problem is glib, which we're not [currently] using. We could
>merge glib into the tree too, but I think it should be possible to
>'translate' most of the glib stuff to equivalent abi/wv stuff.
>Otherwise, I haven't tried it, but it looks fairly standards-compliant,
>so I don't think it'll cause too many XP headaches.
>
>I'd vote not to use glib, but to port libole2 to our framework.
Hmm. That's a tough call to make, because we have to strike a balance
between two competing principles:
- if adding glib duplicates code we already have, that's a waste
- if eliminating glib provokes a fork of libole2, that's a waste
From the description of glib, it does sound like an alternate implementation
of the kinds of services abi developers usually get here:
abi/src/af/util/*
Thus, if everyone will forgive the ASCII art, we're looking at the following
parallel sets of building blocks:
abi --> util
--> libwv --> (whatever Caolan uses)
--> libole2 --> glib
It's not clear to me how big the overlap/collision between the various
support libraries (rightmost on each line of the picture) really is here.
Insofar as each of these lower-level packages want to exist as standalone
libraries, the one thing which definitely *doesn't* make sense would be to
force either libwv or libole2 to start depending on abi's util package.
Ideally, we'd all be able to share a standalone XP libole2 with minimal
external dependencies, so that it could be used everywhere:
- in Gnumeric
- in standalone wv
- inside AbiWord (via wv)
- inside AbiCalc, etc.
I guess the real question for me is -- how heavy is the dependency on glib,
and how much of glib is actually used? I must admit that the discussion of
pthreads support here makes me leery:
http://cvs.gimp.org/lxr/source/glib/README.win32
However, if glib really is small, portable, and actively maintained, then
perhaps there's nothing to discuss here. All I care is that the code Just
Works on our supported platforms, so that we can focus on higher-level
issues.
Paul
motto -- more questions than answers
This archive was generated by hypermail 2b25 : Thu Mar 30 2000 - 17:51:08 CST