HTTP built on a database engine

Sean Martin ([email protected])
Tue, 22 Nov 94 11:31:44 GMT


|>On Thu, 17 Nov 1994, Daniel J. Kurys wrote:
|> We are currently developing server technology that integrates database
|> and full-text engines for searching indexes of both local and remote

On Tue, 22 Nov 1994 Brian Behlendorf <[email protected]> wrote :

>* a real revision control system, with backwards mistake-fixing
>* documents may have many states, some of which may require that they not
> be "public", but readable (and writeable) by a particular group of users
>* publication paths can be set to require certain signatures of approval
> before being publishable (i.e. the editors and layout people sign off
> on it)
>* items on the web server are assigned abstract document identifiers, so
> inlined images can be referenced by name rather than by relative
> location, so URL's don't change even if the document's location does.
>* Upon initial submission of an object into the database, the creator is
> prompted for things like a title, an author, etc. This information is
> needed for non-HTML documents, too.
>There are many spinoff benefits. When documents are "published", the
>full-text search engines can be incrementally indexed, for example.
>

Most of the above is prototyped on www.europe.ibm.com. and I would say that all
Brian describes is all certainly doable. It is possible to treat all WWW
data including gateway/executable programs and imagemaps as objects in a
relational database. Each object posses attributes for display/execution,
management and index/search.

The biggest problem seems to be resistance by users to "funny looking" URL's,
since machine generated references dont look too good. I was forced to
implement something called a LIM (logical inheritance map) which simulates
the "path stucture" in a URL, so that it looks right from the client. I only
use the object reference when actually serving. /go/D00000023 is the same as
/go/ase/powerdev/D00000023.html as far the server is concerned.

>> I would be interested in hearing more discussion of "server dream
>> features" that require a non-cgi approach. What did you have in mind?

I would also be most interest to hear discussion by anyone taking this approach.

Kindest regards Sean.

-- 

Sean Martin, User Systems, ISC, IBM Europe Internet: [email protected] || [email protected] UKnet: [email protected] Sudbury Towers, London, England, UB6 0JA. ** The views above are mine and are not necessarily shared by my employer **