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
Previous text:
2003-01-26 02:38: Subject: Re: Bz2
For me it segfault.... on FreeBSD. I can add a pikefarm target for you if you'd like..
Only if someone intends to fix it. It is not part of a default build because it is not maintained (or used). Otherwise removing it in the 7.5 tree sounds like a good idea to me.
What's wrong with the SSL module, or more to the point, what is better with OpenSSL?
The OpenSSL module that is in the Pexts was submitted in pike@roxen.com ml. It is just a wrapper to OpenSSL calls... So it can be used very easyly with any openssl implementation.
That's not an answer to my question.
Now, what do we do ? Stopping adding modules ? Making an hypotical CPAN like for Pike, or just throw all work that have been done we some interressed ppl in Pike ?
Hypotical? Yes, as I said I believe that making a module system for Pike is the correct path to take. I have already presented an idea for how such a system could look like (on more than one occasion I think), but so far consensus hasn't been made.
Think of the module tree as an Internet domain name hierarchy. Currently the top domain and everything under it is adnimistrated and managed by IDA. My idea is that every subbranch should be open for people to become manager for. As an example I've said that perhaps some caudium guy would like the top module PExt and everything under it. He in turn could delegate parts of that namespace further down.
This framework would provide a way of administrating the module tree in a way that has the potential to be both flexible and "free" while still preventing namespace mayhem, as has been seen in other langauges.
Now, using the same tree of delegation we could make a tree of trust, where every source code, and possibly binary, can be signed by the module owner and his key is signed by the module owner over him.
Again using the same tree of delegation, the location of the modules can be distributed. When someone tries to download the PExt.Foo.Bar from IDA, the server can just send a referrer to the lowest known module owner site in the module path. Eg. for PExt probably somewhere on a caudium site. With a well defined method for listing modules it is easy to create a "module browser" where you can find modules you didn't know about.
(And why do you propose throwing work away as an option?)
/ Martin Nilsson (Åskblod)