} 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
} 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