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
1. 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
2. Skeleton modules should be prepared for the various varieties of
modules.
3. 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.
4. A local install option should be added so that a user may install a
module in their local module tree.
5. 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