Ok...
I've been working on this for some time - but since I'm not a 'programmer'
per se, don't mind the terms I'm using. I expect full feedback on the
list for this discussion - try to keep it pertinent instead of trying to
get 'new' features added as part of the debate.
Modular Client Code...
With each new feature we add to OpenSRS we find ourselves forced to
release a complete version of the client code. Due to severe
customizations that certain customers have made it becomes increasingly
difficult for you to implement the new codebase, and in turn be able to
benefit from the new features being added. With this in mind, we propose
a new client code architecture that is modular in design.
Base components:
OpenSRS.conf - this will contain the usual login/host information, but
will have another section labelled "Modules". This will allow you to turn
on/off any modules that are currently available, as well as add new
modules as they are released
Client.pm - Responsible for connecting the the server, establishing secure
socket protocol, and simple error checking.
Modular components:
Templates - each new module may need new templates. The proposal is to
have a base template infrastructure (base.html, header.html, footer.html,
etc) and specific APTLY named templates for each new feature and customer
facing screen that encompasses the logic of said feature.
This will remove the need for seperate template directories for each CGI -
there will be one directory
Register/Transfer Domain - this will allow someone to register/transfer a
domain - using common templates and logic derived from 'reg_type'
Batch Register/Transfer - same as above, but with batch capabilities and
the logic that necessarily entails.
Manage Domain - the default, but you should be able to remove some
features altogether - i.e. create custom nameservers
<New Features> - somethings that may be available in the near future are
ccTLDs. Certain name spaces have different requirements. These new
modules may have new templates, or share some that aready exist for
reg/transfer - such as picking a profile.
The use of the 'countries' file already makes the OpenSRS client somewhat
modular - a component is loaded when needed for the appropriate task.
We're looking for suggestions to maximize the potential of this proposed
architecture - as well as usability. Administration must be simple (i.e.
adding a new module...)
Adding a New Module:
- Download module components (cgi, template(s), etc).
- Place CGI in cgi-bin - edit to point to OpenSRS.conf
- Place templates in template directory *(should we make the location of
this configurable?)*
- Edit/Enter line in OpenSRS.conf to enable new module
Should be as simple as that....
Please - copious comments are desired :) On list :)
--
Charles Daminato
OpenSRS Support Manager
[EMAIL PROTECTED]
