[Zope] - Requirements for a project development system

[Andreas Kostyrka]

On Wed, 30 Dec 1998, Christopher G. Petrilli wrote:
> This will probably NEVER be doable, even Emacs stumbles over various VC
> models... I don't want to end up supporting RCS, CVS, SCCS, CodeSafe,
> SourceSafe, and about 20 others that I've used/seen... 
That's why storing the website as a file tree is so nice :)

Most of the tools one wants to use know how to deal with file trees :)

> > By "source code" I mean all the information you create for your
> > project: C, Python, HTML, documentation, whatever.  If there is meta-data that
> > is required to make your project work, it should be stored in a human-readable
> > form as well.  An example of this might be permissions on files, which would
> > be stored in the form of a Makefile rule that sets the permissions..
> 
> Um, is it me or are you generalizing Zope out to full version control
> and project management for everything known to mankind?  It's intended
> to manage objects, period, some objects are DTML, some are Python, some
> are all kinds of things... but I've never seen one for C.
Nope. He just states ``sane'' requirements for doing projects.
It's more or less the same as with SQL. I personally detest SQL, and many
collegues working in the sector hate it too.
After using BoboPOS for a small project, and my experiences with it, I
just sounded one question to my collection of SQL haters: Where would they
store legally important (for example invoices, etc.) data. Funny thing,
every one of them admitted that he would store it in a good proven SQL
server, and wouldn't even consider a OODB.

Having been in a philosophical mood then, I thought a bit, and discovered,
that the full integration of data and code in OO programming is not right
for certain data, especially when the client is required to keep the data
longer (by law) than he will probably keep his hardware and software.
(Doctors for example have to keep their records here around for 10 years
 safeguarded, ..., accounting stuff must be kept for 7 years, etc. That
 are time spans, that in the fast moving IT world nowadays can mean that
 there will be more than one software that will have to access the
 same data: Basically, the data scheme and data itself is much more static
 than even software. In some cases this leads to ``new'' mainframe sales
 nowadays: Nobody knows how the data is structured (and what implicit
 assumptions are in the code/data), nor can anybody really understand the
 software, so when the hardware breaks, new (exactly the same) hardware is
 bought as a replacement.)

> > Corollaries to requirement 2: you must be able to build and maintain your
> > project with command-line tools.  Being able to use a GUI or a web page to do
> > things is great, but there is no substitute for the UNIX way.  Windows NT is a
> > good counter-example to this rule.
> 
> I agree that there need to be CLI interfaces to shoving thigns into the
> object database, and getting them out.  BUT, there's nothing saything
> that the following options aren't 100% valid and workable, if you're
> willing to make slight compromises:
See above. Certain data must be as freely as possible available. And
BoboPOS implies:
a) that the live production data is locked in somewhere.
b) that there certain things done that are badly mappable to a filetree.
   (Easy one: How do you express references to the same object?
              symlinks? Wrong answer, because there is no master reference
                        all references are the same.
              hardlinks? Wrong answer, how do you hardlink directories,
    ...
   )
   And there are many other things like this.

> 
> 	1. FTP access
> 	2. Theoretically you could build a VFS interface and MOUNT
> 	   the object database.  I did this once with Versant, it is
> 	   possible.
> 
> > Here are some examples of project tasks that are facilitated by these basic
> > two requirements:
> > 
> > - I want to be able to take a snapshot of my whole project that I can roll
> > back to at a future date.
> 
> This is doable currently, though perhaps not well documented.
> 
> > - I want one team of people to work on part of the project independently
> > without clobbering what another team is doing.
> 
> How do the current draft and session management tools fail at this?
> 
> > - I need to look at the diffs between yesterday's version of the project and
> > today's version to figure out what person X did.
> 
> This needs to be available, it's just a matter of grabbing the revs and
> diffing them.
> 
> > - I want to set up an automated task to check out the latest version of the
> > project from source control and build it on a test machine.
> 
> Um, what does this have to do with Zope?
Exactly *g*
> 
> I'm confused, all this seems more concerned with software development
> than website, and while there some of the former in the latter, they're
> not fully inclusive of their requirements.  I don't expect one widget to
> do everything for me.  I do my Product development in RCS, even though
> the website uses the Zope databse to storee things in.
> 
> I'm just affraid you've made this a MUCH larger issue than it is.
Not really. The problem is that some people consider website development
as software development, especially if you go further than a couple of
nice static webpages. Now if you just want static webpages, than you
can stay with a standard webserver, right? Proven software.

Now if you do develop some code, you'd better treat it as a software
developement project. And SQL queries are to classified as code. (I've
seen projects where the SQL ``programmer'' that supplied about 10 queries
was better paid than the programmer who did all the grunt work.)

Oops, Zope now does SQL, right? So Zope better meet the same ``sane''
requirements for software development.

The problem here is, that for most projects the maintenance is the
deciding factor. Sometime you can bring in ``exotic'' solutions like
Python through arguments like productivity, price, etc., sometimes it just
doesn't matter that our solution will be:
1.) quicker to deploy,
2.) cheaper,
3.) more stable,
etc., just because the client never heard of python and doesn't know
anybody else around here who could maintain python code.

Andreas
-- 
Win95: n., A huge annoying boot virus that causes random spontaneous system
     crashes, usually just before saving a massive project.  Easily cured by
     UNIX.  See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.