At 09:23 AM 4/25/02 +0100, F J Franklin wrote:
>I like the abi-1.2 idea as well, especially since we're likely to be
>changing the directory structure and possibly renaming/moving a large
>number of files.
Oh dear. That could be a real maintenance headache. But you know that,
right? :-)
>We should probably start thinking about the directory structure.
>
>It would make me happy if we could have a clear hierarchy. At the moment
>some UT* include XAP* and/or GR*, and vice versa, whereas (I feel) it ought
>to be possible to have, e.g., UT* self-contained, GR* may use UT*, XAP* may
>use GR* and UT* etc. But is this an unreasonable expectation?
Your expectations are very, very, very reasonable. Indeed, when Jeff, Eric,
and I originally organized the hierarchy, the modules were very clear and
distinct. Among other things, we took pains to:
- build each module as a standalone library,
- enforce naming conventions and APIs to minimize the namespace exposure
of information that was private to each module,
- periodically relocate code that got "lost" in the wrong module,
- etc.
Still, a lot of water's gone under the bridge since those early days, and
neither of us has been nitpicking those issues for a long while now. Thus,
I'm not at all surprised that those formerly crisp lines have gotten blurred
over time.
Doing the "code janitor" work to tidy things like this up isn't most
people's idea of a fun time, but I'd love to see it happen. Are you
volunteering or recruiting? :-)
>For example, the encoding manager sits in XAP but, as other current
>threads attest, encoding is a fundamental part of AbiWord, and should
>probably sit in UT...
I think you may misunderstand the roles of UT and XAP.
UT = low-level utilities
XAP = application services used by more than one Abi* application
Thus, in theory the UT stuff would be usable without any XAP or AP logic,
although to date nobody has wanted to.
In practice the line between the two can seem a bit arbitrary. However, in
principle the UT library should stay lower-level, whereas the XAP modules
are a lightweight framework for doing native GUI applications (AbiWord,
AbiCalc, AbiShow, etc.).
Would moving the encoding stuff down to UT make standalone use of that
library more useful for someone right now? If not, it seems like an awful
lot of work and confusion.
>One thing I'd like to add is an IO category.
That doesn't require a tree reorg, does it?
>Finally, there has been talk of adding plugins to the main tree - how is
>this planned?
I actually liked the notion of plugins being built separately, for three
reasons.
1. It emphasizes that they *are* separate.
2. It provides a pattern for others to create and build new plugins
that aren't now (and may never be) part of the mainline AbiWord
sources.
3. It increases the odds that the APIs exposed to plugins get
concentrated in a few easy-to-find header files.
I'd think that moving them into the main tree might encourage the kinds of
illicit crossing of API and module boundaries that you were alluding to
above. That's unpleasant in the case of static libraries, and just plain
nasty for dynamically-loaded plugins.
bottom line
-----------
Janitorial cleanups to reinforce the original distinctions between modules
have my unqualified support. I'd be happy to review any specific proposals
to this end.
Some tree reorganization may indeed be necessary, and now's a good time to
think about it. Two recommendations, though:
1. For now, decouple that discussion from the CVS vs. fork one.
2. If a fork really becomes necessary, fork away the *legacy* tree. The
mainline of abi development should always happen in the abi/src tree.
Paul,
code janitor
