I like the design. However I dislike the amount of implementation necessary to start adding new modules (or moving the PExt modules).
I propose a simpler implementation:
o Decide on a suitable module tree o Decide who is responsible for what parts of that tree o Document this on a web page o Make sure everyone has sufficient access permissions to the cvs o Hope that people can communicate with each other and solve problems o Use the existing packaging and distribution systems
That way you can work on new modules and on the new very cool module system in parallel. Serializing those two processes seems to be a sure way to kill of progress.
/ Mattias Wingstedt (Firefruit)
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)