The problem I'm solving is administration and hosting. You might not percive the convention to put all modules in a big centrally administrated and controlled repository as a problem, but I do. I don't think it is a good idea to create a playground-module namespace, because stuff that gets in there will most likely stick. Other than your second item I don't see that you are contradicting my suggestion in any way.
/ Martin Nilsson (Åskblod)
Previous text:
2003-01-26 18:57: Subject: Re: Bz2
Your domain name idea seems like a solution that seeks to fit a problem rather than the reverse. I doubt it's good that an organizational/delegation structure is reflected in the module namespace. That will most likely lead to names that are unnecessarily long from a programmers perspective, and it's easy to do better if there is any sort of central coordination.
The issues that I see currently are:
o Keeping a well designed core library without redundancy and inconsistency. Redundancy is avoided by having a good overview over the current modules so that we readily can point out existing modules when a new one is considered and suggest extending them instead.
Inconsistency is avoided by writing detailed guidelines for libraries and providing a framework to adhere to for basic stuff like collection handling, serialization etc. We already got the framework for serialization and basic collection/iterator stuff (and a more elaborate class hierarchy for it is on the way). What we're lacking is above all an exception system, but also a good interface for streams (both for I/O and internal use).
o Make it fairly easy to add new modules. This can easily conflict with the high standards above. I think a single namespace for all such "uncontrolled" modules is enough. Why not let that area be called "PExts" and plop in the PExts stuff there to begin with?
It should be easy to allocate a name there, so that anyone can get going with a new module without having to raise the interest of some unspecified core developer. I.e. avoid the all too common situation when a request only is met by silence.
The intention should be that this is only a staging area for unfinished modules and that the goal is to extend the core modules instead. It's much easier to use a feature implemented in a consistent way with the rest of the module library than one that exists by itself.
o Improve the C level API. I.e. more docs, make it easier to compile outside the pike tree, reorganize the header files so that the things that modules need are separated from the internal core stuff, etc.
/ Martin Stjernholm, Roxen IS