- A Practical Problem
When someone is granted a spot in the namespace, what are they getting? do they get the whole subtree below where they've been granted?
It makes most sense to me that subtrees should be handed out.
Example: if I get Protocols.NNTP, for the purposes of making a client, can anyone else get their module in that tree or do they have to look somewhere else?
Typically you have already made a NNTP client implementation in a less prominent part of the tree (PUMA.Protocols.NNTP, Author.nilsson.NNTP, PExt.NNTP or whatever) and the Protocols admin wants elevate your NNTP implementation to the official one. Perhaps.
Also, this problem manifests itself in the handling of the installed modules and how to make room for others.
That's just a minor technical detail. The install_module script (in the Pike bin directory) does
if [ -f "$DIR" ]; then mv "$DIR" "$DIR-foo" mkdir $DIR mv "$DIR-foo" "$DIR/module.pmod" break fi
- Namespace Management
There is no need to overspecify this at this moment I think. We can create a top module where everyones modules may live unrestricted and then think of means for how to merge them into the main tree.
/ Martin Nilsson (saturator)
Previous text:
2003-10-16 05:05: Subject: module repository ramblings
I've taken a few minutes to jot down some ramblings concerning a Pike module repository. I know that there was a proposal a while back called PUMA, though I can't find any trace of it when I went to look for it. I'm sure that it has some very good ideas that I will have neglected to include here. If that's the case, or if you have any thoughts, please feel free to send them my way.
- Initial tasks that need to be accomplished
- The build/install system should be updated for the various varieties of
modules:
Modules with C component (ok) Modules with C and one Pike (ok, but see the problem below) Modules with C and multiple Pike Modules with Pike (see the problem below) Modules with multiple Pike
- Skeleton modules should be prepared for the various varieties of
modules.
- The documentation build tools should be modified to allow partial
merging of new documentation. The extracted documentation should be installed to facilitate the documentation process.
- A local install option should be added so that a user may install a
module in their local module tree.
- A method for passing arguments to the configure process should be
developed.
- A Practical Problem
When someone is granted a spot in the namespace, what are they getting? do they get the whole subtree below where they've been granted?
Example: if I get Protocols.NNTP, for the purposes of making a client, can anyone else get their module in that tree or do they have to look somewhere else? I worry that we'd end up with essentially a 2 level module tree.
Also, this problem manifests itself in the handling of the installed modules and how to make room for others. If a module is installed like this (example Protocols.NNTP):
lib/modules/Protocols.pmod/NNTP.pmod (single pike file)
how do we handle someone wanting to create Protocols.NNTP.Server?
would it be better to have all modules installed as module.pmod within ModName.pmod direcories? This would give the maximum amount of flexibility as far as making room for other modules to be slid in, but really seems inefficient, in that we'd most likely only have one module file per directory.
- Namespace Management
Coordination of the namespace will be handled by a namespace management board ("the Board"). The board should be made up of not less than 3 developers. The board should reflect the makeup of the Pike user community, with representatives from the IDA team, core developers and non-core developers.
Q: Should there be requirements for membership and/or rotating positions?
The Board is responsible for the smooth operation of the repository, and for keeping the namespace manageable. The Board is the final authority for handling namespace issues that may arise among developers. When practical, the Board should attempt to obtain consensus among its members when making decisions.
The Board may delegate responsibility for a given branch of the module naming tree to a non-Board member, though the Board will always retain the right to assert control over delegated branches.
Coordinators of delegated branches must remain active in thier role. If such a developer is no longer able to perform the duties of a branch coordinator, they must return control of the branch to the Board. All coordinators should be contacted on a regular basis (several times per year) to verify that they are accessible and able to carry out these duties.
- Duties of coordinators might include:
a) granting positions in the tree to other module developers b) assisting module developers in making wise decisions concerning module and class naming c) making sure that modules in their respective section of the repository comply with the requirements for inclusion (quality control)
- Adding modules to the repository
Before a module can be contributed to the repository, the module's author must request a place for that module within the module namespace. The request should include at least the following:
a) Developer Name b) Contact Information (at least email, but potentially other means) c) Proposed module location in the namespace d) Estimated scope of namespace usage (subclasses and possibility of other modules beneath) e) Request for coordination (if the tree is not already delegated)
Ideally, the process for making requests and having the requests approved would be streamlined and part of a semi-automated workflow.
- Requirements for modules in the repository
All modules must meet the following requirements (quality control):
a) Author name and contact information must be provided b) License must be clearly declared c) Version of the module must be included as a constant in the module d) API Documentation (should be provided), and must be in autodoc format e) Modules must use the standardized build and installation interfaces f) Modules must not cause interference with other modules in the tree
A directory of information about modules in the repository will be maintained by the Board. This directory should contain information about modules, their function, changes and versions, compatibility and dependency information. A distributed network of nodes will make the directory and the modules themselves available for access by users. The directory will also be used to provide a web service that will allow a user to locate, download and install modules automatically.
Well, that's about all I have for now. Please give me your thoughts, flames and other assorted musings.
Bill
/ Brevbäraren