httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Skolnick <cl...@organic.com>
Subject Re: SSI handlers
Date Mon, 10 Jul 1995 15:53:54 GMT

} But, this is how server-side includes *work* in Shambhala (each
} inclusion directive generates the same internal data structure as an
} actual client request, with a few extra notations; see the API docs on
} the sub-request mechanism.  This means, in particular, that they are
} *already* subject to content negotiation, if the item being included
} is such that content negotiation would come into play on a direct
} request). 

Kindof, I was thinking of more complicated objects than files.  I'll go back
and read the API again, perhaps I missed something.

} Performance is important to people.  I actually think most of the
} current servers get performance as good as you can expect out of the
} current HTTP spec, and in fact, I'd be happy to stick to a forking
} server, except for one thing, which is HTTP-NG.  The performance issue
} which *it* addresses is gaining adequate network performance in the
} face of TCP slow-start, and that issue is very real.  However, I don't
} see any easy way of implementing HTTP-NG in a non-threaded server,
} hence my desire not to commit to anything which would close off that
} option. 

I'm not sure we will need threading for HTTP-NG.  I don't see why one
thread can't handle multiple requests at once to be honest.  All you
really need is some sort of async I/O.  This can be simulated in an OS
neutral way, unlike threads.  Of course many of the same concerns and issues
would be the same in the code.

} Ummmm... in such an environment, is there any reason for the server
} not to use the NFS interface as well, which would eliminate the need
} for special code to interface to the database?
} 
} (Carrying this further --- if stuff in the database is edited as if it
} were in the normal filesystem, and retrieved as if it were in the
} normal filesystem, what is the database offering which is *not*
} offered by a normal filesystem?  Before getting lost in implementation
} detail, it might be wise to step back a bit, and write down someplace
} exactly what you want to achieve by integrating the database, so you
} can be sure that the machinery you come up with achieves those goals).

I used to say the same thing.  I could spew for hours on how a file
system is just fine for a server.  I mean a pile of documents and a file
system just "work" the same way most of the time.  But working at Organic
I've seen a bunch of things than make me want more than the UNIX file
system provides.  I guess I could switch to VMS (cough, choke) or use something
that provides:

	1) Lack of versioning

	2) Backup/recovery

	3) Mirroring

	4) Performance

	5) Multiple front ends to the same data

I really want a nice stable, logging, easily backupable, pile of 
objects :)  For now I am off in the direction of a log based file
system, CVS/RCS, and dump/restore.  But I'd prefer a nice integrated
solution.  Come to think of it, I can now spew for hours on how
you want a database now...Certainly all these issues can be addressed
by various solutions (even 5 can be addressed with NFS), but databases
are designed to do this sort of thing.

As web servers move into more transaction based things you will need a
database hooked to your web server anyway.  Why not just use it to handle
all the data issues, not just transactions.

I don't expect the Apache group to do this, but I do want to see APIs that
support a database vendor or an interested third party (like Organic)
doing this.  This is the future.

Cliff

Mime
View raw message