next message in archive
next message in thread
previous message in archive
Index of Subjects
For those that haven't been following this thread, this is part of
a discussion that has been happening about the development of the Nova
Scotia Provincial server and whether it would appropriate to move CSuite
in the same direction.
On Aug 5, 11:00am, Jeff Warnica wrote:
}
} Im not speaking for anyone but myself here, but with our internal efforts
} going towards supporting PPP and developing/supporting the new provincial
} server (with no (telnet/ssh/r-)logins, if that hasn't been mentioned) CSuite
} v2 might be completely different: only a epsilon part of the admin back end
} would bear any resemblance to 1.x
I think it will be several years yet before Community Nets can
move completely away from standard text logins. At this time it is
easy for the financially disadvantaged to get older computers (ranging
up to 386's and low-end 486's), since these are basically give-away
items. However, these machines are not suitable for running current
Internet apps. For that, you need a high-end 486 (486DX4/100 w/16M RAM
and 500M HD minimum), or more preferable, a Pentium class machine.
These machines still cost real money, which a large portion of the
population can't afford. The whole idea behind Community Nets is to
bring the Internet to everybody, in particular the financially
disadvantaged. For this reason, I do not see the text interface going
away in the near-term. I see CSuite 2.0 being very much like CSuite
1.0 with some extensions. The main extensions I see are support for
addtional languages (Spanish was brought up locally), better support
for accessing it remotely, and fully integrated Virtual Community Net
support (this is currently very much needed for the various provincial
server projects).
I would like to get comments from other CSuite users/sites on the
above.
} Official or not I think most of the prople working on the new suff for the
} provincial server (Csuite v2) realise that sql is the way to go, if just
} because most of the stuff will be run from inside a phpN script. We /could/
} have every php script call out to other programs, but we would have to
} rewrite everything, anyway.
So far I have not seen a good reason for moving away from namedb
to a more complex SQL implementation. The limitations of a particular
scripting language (in this case, PHP) simply do not count. If a
language can not handle your needs, then use another.
There are a number of poor design decisions in CSuite. This isn't
to say that the original people that wrote CSuite did a bad job, just
that they weren't experienced/trained in handling large projects.
CSuite is an amazing accomplishment, and works very well. However,
there are parts of it that could be better. One of the main problems
with CSuite is the lack of modularity. This is essential in a large
project like CSuite in order to make it maintainable and extendable
(basic software engineering principals come into play here). This
means that, as I mentioned before, the first step in changing the user
database is to abstract the interface to it. This makes the PHP issue
moot, since all the scripts (PHP and otherwise) would call one program
(with a predefined interface) that would handle all manipulations of
the user database (both querying and modifying). If you have to
rewrite everything anyways, then it is a good opportunity to design it
and do it right, instead of keeping the same haphazard methods. This
way, if the user database ever needed changing again, all that would be
needed is to replace/update the one program without touching any other
part of CSuite.
As the current nominal head of CSuite development, I intend to
move it in the direction of cleaner code / modularity. I will be
abstracting the interface to the password database during the current
development cycle so that I can add support for NIS+. After doing
that, it will be very simple to add support for NIS, PAM, LDAP, and
whatever else may come along in the future, just by updating a couple
of files, instead of 20+ files. It also means that CSuite will work
better with the BSD password database (support is already in CSuite;
although, I don't know if it has ever been tested).
} Though it hasent been mentioned, if this ever scales to mutiple machines,
} its a lot easier to scale SQL to mutiple machines because it is already
} client-server.
This is the only good reason that I've seen for moving the user
database into an SQL database. We could, of course, make a
client/server wrapper for namedb, but to get it right is probably more
work then it is worth. However, I'm not sure how much of a concern
this is, since the trend for most projects of the size of CSuite is to
simply use a bigger machine. Most CSuite sites do not have skilled
system administrators available and have enough trouble handling one
machine, nevermind multiple machines. It is much easier and cheaper to
administrate one machine then it is to administrate a network with
multiple servers. There are a few larger sites that are lucky to be
run by professional system administrators (who usually have "day"
jobs), but that is not the norm.
}-- End of excerpt from Jeff Warnica
next message in archive
next message in thread
previous message in archive
Index of Subjects