next message in archive
no next message in thread
previous message in archive
Index of Subjects

> -----Original Message-----
> From: ccn-tech-owner@chebucto.ns.ca
> [mailto:ccn-tech-owner@chebucto.ns.ca]On Behalf Of John Nemeth
> Sent: Thursday, February 22, 2001 3:38 AM
> To: csuite-tech@chebucto.ns.ca
> Cc: Ccn-Tech; James Carroll; Marilyn MacDonald
> Subject:
>
>
> On Jul 11, 12:49pm, Jeff  Warnica wrote:
> }
> } I think that CSuite 1.x has enough problem that 2.0 should be a complete
> } rewrite. Because of this, we should reevaluate everything. I
> think that the
> } primarily language should move to Perl, or PHP with SQL being
> used for data
>
>      You've brought this up before.  I still don't see the need for
> these.  They, especially SQL, will greatly complicate the innards of
> CSuite and could make fixing it when it breaks very hard, if not
> impossible.
>
>      This is also a perfect example of what I mean by haphazard
> development.  At this point, we only have the vaguest of ideas of what
> CSuite 2.0 will be, yet you are arguing about how to develop it.  This
> is putting the cart before the horse.  You need to know the "what"
> before the "how"  We need to write the requirements spec and the design
> spec before we can even think about these things.  The usage of things
> like SQL may or may not be appropriate; but, until we write the specs
> nobody will know.

True, and while Ive been distributing around (what will likely become a
'offical') CCN wish list with specific packages, it does basicly come down
to just a massive upgrade of 1.x focused for gfx users, what I realy think
the upgrade should be, is to create a solid infastructure so CNs can easily
build whatever they want on top.

>
> } storage; there are more people around who know, and more people
> around who
> } don't know, but want to learn these, compared to shell. Not to
> mention that
> } these languages are for more capable of scaling up for large
> projects. 1.x
>
>      I completely disagree with this.  VTN has over 10,000 accounts,
> which makes it a rather large community net and it doesn't have any
> problems.
>
> } is tied very much to the unix philosophy, and while valid, that
> only scales
> } so big.
>
>      It scales very nicely.

'Scale' not as in works on large sets of data, but easily added to. Yes
software engineering more so then language choice..

A prime example is the data files.. The deliminator is a '|' character.
However, there are no checks that pervent a script from writing in a | in
the middle of a data item, corrupting the data. Someone here - not me - who
is doing graduate level CS courses has said that therefor, in a formal CS
sence, the CSuite database is unparasable.

>
> } CSuite should be two things; new packages that provide
> functionality which
> } is unobtainable now, and glue so that CSuite can talk to
> existing systems
> } that one would want to use. Linuxconf knows how to read and
> write files like
> } /etc/exports, but it doesn't include a NFS server.
>
>      NFS is a standard part of just about all UNIX systems (we won't
> count things like SCO).  Most of the stuff that CSuite uses doesn't
> come standard with the system, or you get extremely old versions, i.e.
> perl 4.0pl36 on HP-UX.  Even when things can be relatively easily added
> using things like rpms, there is still the issue of where everything
> goes and the configuration files.  Also, since we can't expect every
> CSuite site to have an experienced systems administrator, much less a
> skilled programmer, CSuite must be completely turnkey.  This means that
> it has to include everything it needs which isn't normally found in the
> base OS

Lets say that an exploit is found in Apache... What is easier for a
unexperienced sysadmin to do:

rpm -Uvh apache		(on a redhat/rpm system)

or

tar xzvf apache-NNN
cd apache-NNN
./configure
make
make install

or

cd /var/csuite2.0/src/
mv apache apache-dist
tar xzvf apache-NNN
cd apache-NNN
./configure --destination=/var/csuite2.0/etc/httpd bla bla bla to make
CSuite happy
make
make install

Perhaps CSuite should be distributed as a collection of RPMs, so even if it
does the complex third choice, you only have to type in the first. But if
you dont include apache, just require it, then its not your problem.

>
> } The 'business logic' should be separate from the CSuite
> provided framework.
> } Don't hard code policy and business practices into the core system.
>
>      I agree with this.  Currently, there are too many policy issues
> that are hard coded in CSuite.

This would reqire rewiting a lot of stuff as is.

>
> } I don't see any reason why 2.0 shouldn't be OSS; AFAIK the only
> package that
>
>      What would it gain by being completely OSS?

I dont know.. Im warry of this..

>
> } might cause a problem is PINE, and we don't need pine in 2.0.
> There will be
>
>      We may.  It's too early to write it off.
>
> } The development methodology, so far as I can tell, for 1.x was:
> build things
> } for a live system, on a as needed, adhoc basis.  Then sift
> through and see
> } what's really needed, what works and what's broken, and what duplicates
> } functionality, and make a distribution out of it. Don't
> document anything,
> } don't comment anything. Change database formats randomly, as necessary.
>
>      This is pretty much the way it is, and CSuite has some major
> problems because of it.  This is why I'm pushing hard for formal design
> principles.  In the long run, it will be much better.

Yes. Exactly. Design, then build. Steal snippits of code if you must, but
lets break down and do it right, from the base principles.

>
> } Given the crufty nature of 1.x, and that I don't think 2.0
> should have any
> } text interface, I cant see any reason to stay with that code base.
>
>      Many of the users here would scream "blue murder" if you took away
> the text interface.  You could also have serious problems in developing
> countries.  Given that we want to spread CSuite around the world, you
> have to stop thinking in terms of the relative affluence of the western
> world and think about what you would find in developing countries.
> Also, a text interface is much nicer for people with disabilities,
> especially blindness.  I think it would be a rather unwise decision to
> write off the text interface at this point in time.
>
> }-- End of excerpt from Jeff  Warnica
>

Well, there is the 1.x series for the people who realy realy want or need
text. I dont think that there is any reason to support text, but with my
plugable design, then one could do a text plugin... Even have rules that
talk to a 1.x system.

next message in archive
no next message in thread
previous message in archive
Index of Subjects