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 should the overall project be renamed to? Gzz is too close to zzstructure.

  RESOLVED: Fenfire. (It's synonymous to will-o'-the-wisp.) Several alternatives were considered, including Growl, Galatea, Silklink, Baroque, Rilix and Qwer, but were discarded for people objecting, or for trademark reasons. Fenfire was the least-objected-to suggestion.

• 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?

  RESOLVED: 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.

• Where does buoyview stuff belong?

  RESOLVED: LibVob. In the new formulation, it's independent of anything and is more graphical than anything else.

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.

There will be an overall project called Fenfire which will depend on all the others. Fenfire is the 'real' system we're working towards.

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 respective maintainers of each package have the final words on things.

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.

Additionally, all packages use UMLLinker for documentation.

The packages are briefly detailed below, with their maintainers.