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