misc. architecture notes

• Mail folder: WWW Talk 1991 Archives
• Next message: Jean-Francois Groff: "forwarded message from connolly@pixel.convex.com"
• Previous message: Tim Berners-Lee: "Document identifiers"

Date: Thu, 28 Nov 91 11:32:02 GMT+0100
From: timbl (Tim Berners-Lee)
Message-id: <9111281032.AA16716@ nxoc01.cern.ch >
To: www-talk@nxoc01.cern.ch
Subject: misc. architecture notes

Begin forwarded message:

To: timbl@nxoc01.cern.ch
Subject: misc. architecture notes
Date: Wed, 27 Nov 91 15:06:02 CST
From: connolly@pixel.convex.com

[Any minute now, my ride to Kansas City for the holidy
 will arrive. In the mean time, here are some ideas.]

WAIS

It's beginning to look like you should try to fit WWW inside
WAIS, rather than the other way around. You need to talk with
those guys about format negotiation and document representation,
and both groups need to combine WAIS docid's and WWW anchor
addresses.

In other words, I think the WWW browser should be a WAIS client.
But come to think of it, there's no reason a browser can't be a WAIS
client, a HTTP client, an FTP client, and an ARCHIE client all at
the same time.

For example, I used to compile WWW support into my browser. Lately,
I changed my mind. Now I compile a separate programe that supports
WWW access. I invoke
        htaccess HTML_ADDRESS
and the stdout of that process is the HTML content of the node.
I pipe that through html2rtf.pl, and display the output. The user clicks
on anchors, and the whole process repeats.

I could, however, use waisq, or an archie client, or an nntp client, or
an ftp client in place of htaccess, write a few more foo2rtf converters,
and support all this stuff. Hmmm... lots to think about.

TEXT OBJECT

I've been reading some of the design notes in your web, and I
was particularly interested in your ideas for a portable text
object. My software uses many of these concepts. I gave up
editing capabilities to simplify the design and make it doable
in two months.

I think you would be crazy to try to do the text object without C++.
Perhaps you could provide a C interface and a sample implementation
in C that doesn't have all the features. But for WYSIWYG displays,
the problem is just too complex to maintain in C.

You should take a close look at TMLib. Some of the implementation
needs rework, but the architecture fits your needs pretty well.
I'm not using any of that code, but I'm using lots of their ideas,
e.g. the model-format-view architecture.

HTML

You need a DTD. Have you seen the SGMLS tools? They parse SGML and
write a line-oriented representation as output. This would be ideal
for format negociation. You could support plaintext and cerainly RTF,
and probably make stabs at TROFF, TeX, and perhaps PostScript.

Have you considered how to embed links in other formats? Please let
me know how you decide to do it in RTF. My idea is to translate:
        <A HREF=foo>text</A>
                to
        {\field{\fldinst HREF=foo}{\fldrslt text}}
[for implementation reasons, I'm currently putting the \fldinst group
 after the \fldrslt group, but that's a minor detail.]

The resulting files still work when loaded into MS Word, though if you
saved them again I doubt the HREF would still be there.

[my ride is here. more later]

Dan