I’m still not going to talk about my attack on the forge infrastructure problems quite yet; the software is coming along nicely, but I intend to announce only after it handles its fourth forge type (yes, that was a tease). But I will say this: I now think I know what the future of forges looks like. It’s called Roundup, and it is astonishingly elegant and potentially more powerful than anything out there. Anything, not excluding the clever decentralized systems like Fossil or Bugs Everywhere.
Here are the big wins:
1. Mailing lists, issue trackers, and online forums unify into *one* message queue that can be filtered in various ways.
2. Scriptable via XML-RPC or an email responder ‘bot.
3. Small base system with good extensibility – just three base classes (User. Msg, File) and the ability to define new classes. ‘Issue’ is a class built on top of these.
4. Arbitrary attributes per issue is basically free, with baked-in support for defining controlled vocabularies.
5. There’s a uniform way, called “designators”, for messages and other objects to refer to each other in text.
6. Small, clean implementation written in Python.
There are some things it needs, though… (Read the Roundup design document before continuing.)
First, namespaces. A namespace is a set of User, Msg, and File objects that belong together. Each namespace gets its own hyperdatabase blob. Each namespace numbers objects separately. Each namespace has a unique name used as a prefix in designators. Thus, if I say [gpsd/msg23], I’m asking for the 23rd msg object in namespace gpsd. Everyone talking to a system system has, at all times, a current namespace. If I just say [msg23], I am designating the 23rd message object in my current namespace.
Why the slash? because, in the most general case, designators will be URIs – as, for example, [https://developer.berlios.de/gpsd/msg23]. Presto! There is now an internet-wide namespace of Roundup objects all of which can refer to each other!
No prize for guessing that a namespace is a project. I’ve actually done two things above – I’ve defined all the required semantics for multiple projects to coexist in a forgelike system, and I’ve created a way for projects to refer to each others’ data even if they’re not on the same machine. Both features will be sources of power.
The subtler thing about namespaces is that they are perfectly orthogonal to the system’s other primitive concepts. This will pay off huge in some ways I can already foresee and many that I cannot yet.
I think the design also needs a primitive object class to encapsulate repositories. But I may be wrong about that; I’m still considering it.