These are all very nice, but I've seen a great many "modular" systems built
which end up completely unmaintainable due to the lack of foresight of the
programmers. To be honest, I'm not very impressed with OpenSRS code to
date:
1. The code must known exactly what's in the templates and where it is. In
most cases the code contains formatting/layout information. You cannot
possibly design a modular system when the code and templates are so tightly
integrated.
2. There are numerous circumstances where the system performs the same task
at different points in time - for instance the new "bulk" code skips right
over one set of verification code to go directly to setup_profile, then
hacks the same verification code in at verify_domain for no particular
gain. I reoriented the code to follow the same flow -- the code is much
cleaner, clearer and about 100 lines shorter!
If I really felt up to it, there are no less than a dozen places where
similar changes could be made. But it's hard to justify the effort, when
the whole system is far too interdependant.
I guess what I'm trying to say is this: your goals stated here are
laudable, but unless the team changes the development style radically,
you'll just end up with even more diverse yet overly dependant code. Rather
than embark on something of this magnitude, why don't you release an
interim version that implements a much clearer structure with no
code dependancies in the templates. The team will learn a lot about
modularization/abstraction, and it will provide a good basis for migrating
to the next environment.
On Wed, Aug 09, 2000 at 11:34:45AM -0400, Charles Daminato wrote:
> 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]
--
Joe Rhett Chief Technology Officer
[EMAIL PROTECTED] ISite Services, Inc.
PGP keys and contact information: http://www.noc.isite.net/Staff/
