|>Mikhail Popov suggested adding Frames to HTML:
|>
|>> a. possibility to reload part of the page, not next document
|>
|>Fine, but this means that each frame must be stored in a separate file so the
|>server can send it (hard on document authors) or that the server chops out the
|>requested frame on demand (hard on server compute time).
Not necessarily. The fact that several popular servers work in this way does
not mean that all do. In fact one server I know of runs on a machine where the
concept of a file is meaningless.
Even amongst file based operating systems the UNIX model of `all files are
linear sequences of characters' is not universal. There are many systems that
have working models. The problem cited is yet another reason why the UNIX
file model is broken.
|>The overhead on getting a whole text page is not that great unless the page is
|>many many screenfuls long, in which case it would be better to split it up into
|>a series of documents anyway.
Better for whom? There are many instances in which obtaining a file as a single
unit is much more convenient. For example when editing I do not want to be
concerned with the fact that a single logical document is accessible at the
chapter level as separate texts.
The model I was considering was based on progressive editing modes, the simplest
of which being :-
1) Delete all and replace (ie what we have now)
2) Append to end (Terminal style interaction)
3) Merging Differences
To give a concrete example, imagine we have a persistent connection to an
asynchronous source, might be a room in a MUD or conference system for example.
The first two modes are quite natural, we enter a new room and the whole
situation is changed what we want implemented is `clear screen' logicaly
this is `delete all and replace'. The append function is usefull for `frodo
enters by the east door type messages'. IRC is an example of an append only
interaction mode.
Merging differences needs a bit more care since there is more than one way to
do it. Here the likely usage is as a collaborative editing system in which
multiple users are performing some sort of discussion. Imagine we have an IRC
or a WIT off to one side and a moderator editing a consensus document. As the
moderator enters changes these must be notified to the other participants.
I prefer a structure which uses the structure of the HTML to provide location
information. For example how about:
H1:2/H2:4/H3:3/P:4/10,15
Being the tenth to fifteenth tokens in the fourth paragraph in the third
H3 within the fourth H2 within the second H1.
Actually this is nonsense in terms of SGML because H1s etc are not containers.
You need to incorporate Divisions for that. But remember the motto `screw SGML'.
OK given such a labeling scheme we can define a few editing operations.
Delete, Insert, Replace to operate on the texts. We then work out the minimal
editing operations to trasfrom one text into another. This is called
Unification in the AI world, something I tend to associate with shaven headed
people wearing safron robes and carrying bongo drums but there you are.
I would also humbly submit the same scheme to be used as an extension to the
anchor label scheme in HTML proper ie say
http://bongo.cern.ch/fred.html#H1:2/H2:4/H3:3/P:4/10,15
I would also like a similar scheme for text/plain. There we need two index
methods, row/colum and octets from start:
fred.txt#1,3:4,6 row 1 col 3 through row 4 col 6
fred.txt#3:56 byte 3 for 56 bytes
-- Phillip M. Hallam-BakerNot Speaking for anyone else.