Browser architecure changes

See also: new architecture.

We would like to tidy up the architecture at this point (Oct 91), in order to get as much common code as possible between the browsers. This will mean

The web and anchors is be managed by an anchor object basically like Anchor.m in the NeXT version, translated into C.

The hypertext object, whose implementation will be different for each browser, will be functionally similar to the HyperText object in the NeXT browser, but will have the parsing routines removed.

It is the design of the basic X application, and the design of this hypertext object, which will mainly concern your group. It would be best if the object allowed editing of the text as well as display, so that the application will be a browser/editor, like on the next. In order to be able to regenerate the SGML, the object must be aware of nested regions of the text, and associated styles. The operations which are used be a parser to build a hypertext are basicallycreate hypertext

set editable(boolean)

set title (char* title)

start anchor (void* anchor_id)

end anchor

start style(style* style)

end style

append text(char * text)

flush hypertext to screenThe hypertext object will not need to be aware of the anchor data structure. The application will be responsible for ensuing that any mouse or keyboard events are passed on to the hypertext. The hypertext will allow editing (if the document is writable), and if an anchor is selected, will call the protocol module to jump through that anchor.

Notice that the set of operations above could equally well be interpreted by an SGML generator module. An edited hypertext object should also be able to dump itself, by reproducing a set of calls to these operations on a protocol module which will generate SGML (etc).

We want to introduce the format negociation part of the protocol too, but that will not affect the hypertext object, it will only be in the protocol layer.


Tim BL