next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects
an operating system i
> What is wrong with "mucking around with other peoples code"? It
> is common practice to modify code that one finds on the Net to meet
> their need. Also, it isn't done just for fun. Modifying code is done
Ok, prehaps Im just bitter about spending 2 hours rebuilding apache with
some new modules only to have csuites apache over ride :80 on me. Its a
implementation trade off, csuite proably shuold have a 'required software
list' - with things like apache, perl and the like, and if they arnty there
it should spawn off a install procedure for them...
I suspect the usul target system for cuite (today) is some kind of linux
install, and there are easy ways to upgrade not-quite-csuite packeges with
modern linux's, .rpm's and .deb's...
> for one of the following reasons: integrating it with CSuite in order
> to make a turnkey, easily installed, maintained, and supported system;
By putting everything under $cs_root you make it so admins have to have
special case abilities to maintain it.. If you put all the support packages
where the maintainers of the support packages think they should go, then
csuite admins can refer to the support packages documentation and community
for help.
While it makes instalation easier, it makes continous upgrads more
difficult.
> The most common change is to add a single target to the Makefile
> to get the package to install in the right place, followed by changes
> to configuration files to make the package behave the way we need. Of
> course, the whole purpose of a configuration file is to customise the
> operation of a package, so changes to them don't count.
Have a csute.rpm with dependencies on apache.rpm etc...
> } And thats not even inclugin people who arent quite programmers but can
find
> } there way around a 5gl like Access that cant touch *db at all.
>
> I've never heard anybody describe Access as a 5GL before. In any
> event Access is a toy, not a serious database. Besides, even if the
> account database was stored in an SQL format, and accessible to people
> using Access, that doesn't mean that anybody could just sit down and
> start mucking about with it. First, they would have to figure out the
> format of the database (schema) and what data was acceptable. If they
> wanted to modify the database (i.e. add a field, or add additional
> acceptable values to an existing field) they would have to deal with
> CSuite's front end and possibly the interface to database. Things
> aren't as simple as you are trying to make them sound.
Well, I just use Access as an example, and Im only talking about read only
access *cough*.. The idea is to beable to give more people abilities to
maintain the system: currently one has to be a unix guru with a significant
time invested in learning csuite to beable to add to the project - either at
a internal to you community net, or in the core csuite developement effort.
There are lots of times where you might want ro connectivity to the db's,
data mining being quite important. Just about all languages have hooks for
sql, even 'toys' like Access or Excel.
In the big picture creating a {access|vfp|vb...} SDK is not a lot of work.
In the last coule of months here, three different people have tried to
anwser the same question (total usership, IIRC) with three different methods
of sucking information from the db's. And the've gotton three different
anwsers.
This well could be a GIGO problem, but it does point to some king of
fundmental lacking in csute, a flakey db, or just a undocumented one.
next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects