next message in archive
next message in thread
previous message in archive
Index of Subjects
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.
} 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.
} 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
} 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.
} 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?
} 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.
} 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
next message in archive
next message in thread
previous message in archive
Index of Subjects