directory structure (was Re: New development plans)

From: Paul Rohr (
Date: Thu Apr 25 2002 - 12:20:31 EDT

  • Next message: Paul Rohr: "Re: New development plans"

    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

      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

      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.

    code janitor

    This archive was generated by hypermail 2.1.4 : Thu Apr 25 2002 - 12:21:02 EDT