gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz] Splitting PEG


From: Tuomas Lukka
Subject: [Gzz] Splitting PEG
Date: Thu, 20 Feb 2003 16:34:15 +0200
User-agent: Mutt/1.4i

=============================================================
PEG projectsplit--tjl: Splitting and renaming Gzz
=============================================================

:Author:   Tuomas J. Lukka
:Last-Modified: $Date: 2003/02/20 11:28:22 $
:Revision: $Revision: 1.8 $
:Status:   Incomplete

Issues
======

- Do we need to get rid of zzStructure?

    RESOLVED: Yes. Using a patented technology that
    will not be openly licensed is strictly against our
    free software philosophy. 

- Does this take away the whole basis of the project?

    RESOLVED: No. Even though we *started* from zzStructure,
    the project has in fact outgrown it. The structure
    gave us good insights and points of view (bidirectionality,
    fine-grain hyperstructure, ...), but in practical applitudes
    the code to handle the structure was always more complicated
    than it should have needed to be.

    We have developed several interesting technologies
    that we can *easily* slot around some other structure
    (vobs, uml linker, storm, ...).

- What about Xanalogical hypertext? Can we use that?

    RESOLVED: Yes. Ted has said it's not patented, it was
    only protected by trade secrets, and since the technologies
    have now been openly disclosed, there are no limitations
    to their use.

- Should we really split the code?

    RESOLVED: Yes. It will be far easier for others
    to use our code in smaller, easily digestible pieces.

    It's a psychological thing: it's just easier for outsiders
    to approach.

- What granularity should we be splitting up with?

    RESOLVED: Maturity, function and independence.
    I.e. split metacode, storm, &c, but don't split 
    opengl and awt vob stuff.

    The idea is that we have the core project
    that produces spin-off projects every once
    in a while, as bodies of code mature and 
    are refactored into being more independent.

- Should we really have a separate XuStorm package?

    RESOLVED: Yes. It certainly doesn't belong in Storm: 
    putting any xanalogical stuff there will just muddle
    up potential users. On the other hand, combining
    it with higher level stuff makes it harder for someone
    to just get the xu stuff.

- Who will have what powers in the new packages?

    RESOLVED: Each package will have its own maintainer
    who will act as the "enlightened tyrant" of the package,
    having final say on PEGs for that package etc.
    This is a great responsibility and needs to be distributed;
    currently too much is in the hands of one person.
    
    The different packages and their goals and maintainers
    will hopefully clarify the goals and have the decisionmakers
    close to the actual work..

- Where does mipzip stuff belong?

    RESOLVED: Even though it is currently only used for xanalogical
    images, it belongs firmly in the vob package.

- What should be the basis for licenses?

    SUGGESTED RESOLUTION: Originality. If a package
    is just an implementation of something already well-known
    and already implemented somewhere, LGPL would be preferred.
    For original work, GPL is preferred because it gives more 
    incentive for others to make free software.

Changes
=======

The Gzz project will cease to exist: despite not being 
an acronym and being a buZZword, Gzz brings zzStructure to
mind too easily.

The code that constitutes Gzz will be split into new projects
in a layerwise fashion: some will depend on others but with
as much independence as possible. This will enable reuse by
others.

The new projects (in order from least dependencies on others to most)
=====================================================================

The following sections explain the new projects and what needs
to be done for the first proper standalone release.

All projects shall continue using the PEG style process for
frozen APIs; this is especially important since now others may
begin to rely on those APIs. However, PEG 201 shall be changed
so that 

The initial dependency structure is shown in the diagram below.
There *may* be at least one more package needed, for example if
the same classes in ``gzz.util`` are used by more than one package.

..  UML:: projectsplitting

    package UMLLinker

    package Storm
        use UMLLinker

    package XuStorm
        use UMLLinker
        use Storm

    package LibGLMosaicText
        use UMLLinker

    package LibVob
        use UMLLinker
        use LibGLMosaicText

    package LibPaper
        use UMLLinker
        use LibVob

    package TheCoreProjectThatHasNoNameYetButIsTheRealOverallGoal
        use UMLLinker
        use Storm
        use XuStorm
        use LibVob
        use LibPaper

    ---
    XuStorm.c = Storm.c + (100, 100);
    LibPaper.c = LibVob.c + (100, 100);
    LibGLMosaicText.c = LibVob.c - (100, 100);

    TheCoreProjectThatHasNoNameYetButIsTheRealOverallGoal.c = UMLLinker.c + 
(500,0);

    .5[Storm.c, LibPaper.c] = .5[UMLLinker.c, 
TheCoreProjectThatHasNoNameYetButIsTheRealOverallGoal.c];
    Storm.c = LibVob.c + (0, 300);

The packages are briefly detailed below, with their maintainers.

---------
UMLLinker
---------

:Maintainer: Asko Soukka
:License: GPL

A software engineering documentation tool using ReST and providing
multidirectionally hyperlinked UML diagrams.

-----
Storm
-----

:Maintainer: Benja Fallenstein
:License: GPL ?

A new type of distributed computer storage framework with global, unique
ids.

Todo:
"""""

- Figure out whether to do the "storm2" headerless stuff?

- URN-5 code should be moved into this software

--------
Xu-Storm
--------

:Maintainer: Tuomas J. Lukka or Benja Fallenstein
:License: GPL ?

An implementation of xanalogical hypertext on top of the distributed Storm
library.

---------------
LibGLMosaicText
---------------

:Maintainer: Tuomas J. Lukka
:License: LGPL

An OpenGL library interfacing to freetype, providing
fonts in textures, able to dice.

Uses templates to provide flexible interfaces, allowing
flexible geometry processing by the programmer.

------
LibVob
------

:Maintainer: Tuomas J. Lukka
:License: GPL ?

A graphical library providing automatic animation between unrelated
views, if the views are reasonably defined.

Todo:
"""""

- Take out all Gzz-related renderables

- Make the renderable structure better and easily extensible by
  external code

- document well

--------
LibPaper
--------

:Maintainer: Janne V. Kujala
:License: GPL

A library which creates unique backgrounds from given seed values.
The backgrounds are maximally recognizable as well as legible for black
text.


Todo:
"""""

- License change to GPL

- Might it be possible / feasible / worth it to untie the code from LibVob;
  possibly later.

-----------------------------------------------------
TheCoreProjectThatHasNoNameYetButIsTheRealOverallGoal
-----------------------------------------------------

:Maintainer: Tuomas J. Lukka
:License: GPL ?

Todo:
"""""

- Figure out the new structure

- Write the code to make use of the new structure














reply via email to

[Prev in Thread] Current Thread [Next in Thread]