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

Index of Subjects
On Jul 17, 10:21am, "Jeff Warnica" wrote:
} > -----Original Message-----
} > From: John Nemeth [mailto:jnemeth@victoria.tc.ca]
} > Sent: Saturday, February 24, 2001 10:27 AM
} > To: Jeff Warnica; csuite-tech@chebucto.ns.ca
} > Cc: Ccn-Tech; James Carroll; Marilyn MacDonald
} >
} > On Jul 15,  8:36am, "Jeff Warnica" wrote:
} > } > -----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
} > } >
} > } > On Jul 11, 12:49pm, Jeff  Warnica wrote:
} 
} > } >      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..
} >
} >      I would have to disagree with this as well.  You can add any record
} > type you want.  Things that don't care about the type you added will just
} > ignore it.
} 
} To have any chance in making modifications to CSuite, one has to come close
} to understanding the whole thing. Small changes in one place frequently have
} the effect of breaking something elsewhere.

     This is because of the general design (or lack thereof) and has
nothing to do with the method of storing data.  Having dug around
inside CSuite extensively, I will say that you can add any record type
you want, just don't reuse an existing one.  This, of course, leads
straight to the lack of documentation, since you now need to know what
record types already exist.  This fact doesn't change regardless of the
method of storage used.

} > } 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.
} >
} >      This could be said about any "database" that is kept in a text
} > file, such as /etc/passwd.  It could also be said about several popular
} > data interchange formats such as comma delimited and tab delimited
} 
} Yes. I was not arguing agianst csuite data formats, but text based data
} formats in general.

     Text based data formats have proven to be very useful in the real
world.  There is nothing wrong with them per se.

} > files.  I have to ask just how much real world experience this person
} > has.  I did CompSci at university.  One thing I quickly learned when I
} > got into the real world is that things aren't nearly as cut and dry as
} > they are in academia and that theory must be tempered with practical
} > reality.  There is nothing wrong with storing data in a text file.  In
} > fact text files do have certain advantages in that they are easily read
} > and manipulated by both programs and humans, as well as being easy to
} > repair with any standard text editor when they get corrupted.  I will
} > agree that programs shouldn't be willy-nilly reading and writing the
} > data storage on their own, but rather should go through a well defined
} > interface, but that is orthoganal to the actual data storage method.
} 
} Ok. But if your going to rewite all the data IO, then why dont you move to
} SQL? If text databases were the way to go then the second largest software

     Why should you move to SQL?  I'm not against change per se, but I
am against change for the sake of change.  There needs to be solid
reasons and definite benefits for a change before it is made.

} company would be viINC, not Oracle.

     I wasn't trying to imply that it would scale indefinitely, just
that it was more then adequate for CSuite's needs.  Oracle is designed
to solve problems that are several orders of magnitude larger then any
CSuite system will be.

} It could be argued that being able to edit data by hand is a bad thing. With

     It could be, but it wouldn't be much of an argument.

} modern SQL systems, you can do rollbacks, and transaction tracking. You know

     The fact that records aren't deleted from the CSuite database, but
rather that new updated ones are simply appended gives rollback
implicitly.

} what program/person modified what, and you know what it used to be. Being

     Is transaction tracking of any value for CSuite?  Especially, when
you consider that just about every change would be made by some script
that is automatically invoked.

} able to hand edit text files is not necessaraly a good thing due to security
} concerns.

     This is a completely bogus concern.  If somebody really wanted to,
they could edit the binary files kept by a database.  Or they could
crack/obtain the dbadmin password and manipulate them.

} > } 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)
} >
} >      CSuite currenly runs on three different OS'es, and may run on
} > others as well in the future.  My current favourite OS is NetBSD, and
} > given that there was a request for a NetBSD port on the [survey], I'm
} > considering doing it (I did both the Solaris and HP-UX ports, so I have
} > a very good idea of what needs to be done).  Given that CSuite needs to
} > be portable, rpms (or, any other OS specific technology) is completely
} > out of the question.  Heck, just try installing an rpm on CCN and see
} > how far you get.
} >
} >      Even, if we did consider using things like rpms, we would still
} > have to tangle with things like where files are placed on different
} > systems, how to correctly modify the config files for our needs, in the
} > case of something like apache whether or not the correct modules are
} > installed and if not how to install them, etc.  It would quickly turn
} > into an unmanageable nightmare.
} 
} If CSuite is supposed to be a turnkey system, then shouldnt it include the
} OS as well? RedHat (for example) is aviable for intel, sparc and alpha based
} machines.

     The idea is to ship it with RedHat, but that doesn't mean we want
to force people to use RedHat.  This would probably not be a popular
move since there are a number of sites that don't use RedHat, including
both of the main development sites (for this reason alone, it will be
ensured that CSuite runs on multiple OSes).

} Would it be a big leap to say that CSuite 2.x requires Redhat? That way the

     Yes, it would.  RedHat is utter crap!  It just happens to be
popular crap.  I will not run RedHat on my main servers, and I suspect
that a number of other sites wouldn't either.

} problems of not quite CSuite packages (like perl and apache), and conf