Re: [zzdev] Re: [zzdev] Re: [zzdev] Killer Apps (was Re: How'd it go?

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> Yes, this is probably the ultimate list. But definitely not a minimal
> subset ;)

I know. I just couldn't decide... :)

> How about defining the minimal subset as what we need to generate the
> gzigzag.sourceforge.net site and the included documentation (spec,
> cybertext, designproblems)?

*nod*

> The markup includes running text, style changes (code style and emphasis),
> headings and images,

Also does templating, and this is important. Needless to say, insertion
into templates must be based on structural connections, not string
matching.

> which are figures which could eventually (and SHOULD)
> be drawn using ZZ cells (all current figure editors suck).

I'll leave this to you when we have the subset; I'll take care of
scripting, which I need much more.

> For the site, it also includes the left-side navigation bar. This would
> naturally be taken from the structure.

This should be done with scripting, once we have it. Before, we can just
do it hard and clone it into all pages (selection of current page is a
bit tricky then, but's an intermediate, after all).

> I think that the harder part with this is to spec it: surprisingly, ZZ
> makes programming so easy that once a clear spec exists, I could probably
> crank out an implementation in one night.

Well, as I see it we need
- a plain text format
- links
- parallel markup
- references to whole pages / HTML fragments
- inclusion of parts elsewhere
- templates & parameter passing

Plain text should be a vstream; we should extend vstreamraster to do
multilines, and a line break is converted to a HTML paragraph break. --
I know the tricky thing about newlines is what to do with them in
ordinary cells; however, we can for the time being define Enter to have
a special meaning when editing text, like: create two new cells along
d.2, the first a clone of a <p> cell (or something), and move the cursor
into the second.

HTML links are many-to-one and thus can be represented along a single
rank -- for convenience in the current system, let's say d.1, the linked
thing being the tailcell. Then, you can go to the target of a link by
hitting End, Right and browse the links to a target by hitting Left (and
Right). This implies that the whole content of the link is in one cell,
and that there's nothing else in that cell. Most often, this is right;
sometimes it isn't, then we use parallel markup; in the first
implementation, we may even forbit this at all.

I'm working on a link view, which visualizes that kind of structure in a
double tree: the accursed cell being root for an upwards and a downwards
tree. With that view, we can show all pages that link to a page and all
pages a page links to easily, the words of the link being visible on the
connection lines. Editing this is possible (though not as easy, because
there are some tricky key binding problems).

A parallel markup for a plain text is a list on d.2 (does it make sense
to inherit, on d.3?) of tags associated with vstream spans. These tags
can have structparams. They are connected to the actual text by a start
cursor and an end cursor, the start cursor hanging from the tagcell, the
end cursor from a dummy cell poswards on d.1 (when there are
structparams, they hang from that cell). Tags may also have only one
position, if desired.

To make this useful, we need "weighted cursors:" when the cell the
cursor is on is deleted, there must be a precedence list of directions
in which the cursor tries to go. If a markup cursor moves to a linked
document on d.1, we do have a problem. I'd say we start having
structparams on the cursor cell (also need these for stuff like
cursor-specific home cells etc).

The nice thing is that we can bind a view (in vstreamraster mode) to a
cursor of a tag, and move it around as we desire. Curseling around :)
Parallel markup lists can be bound to the reference cell of a HTML
fragment/page on a dimension d.markup.

The headcell of a text vstream is considered the page (or maybe HTML
fragment) cell, and should contain the title. This shouldn't be put
elsewhere, or be split up among cells, to make real structure
visualization & editing, as described here and otherwise, possible. Thus
the first cell on d.2 must not be considered part of the vstream, but
its title (shouldn't be that hard to do, I think). Links to the whole
fragment, on d.1, go to that cell. (If you want to link to a point
inside a page, using an anchor, create an empty cell in the vstream and
link to it on d.1.)

For convenience, let's assign file names to HTML pages. A file name is
linked to the page's title cell on d.URI. The URI cells are linked into
a hierarchical structure (surprise ;) ). The HTTP server then serves the
right pages for a given filename, and attatches the right filenames to
links. But the first implementation might also just use the raw cell
addresses (which should probably also stay accessible later).

Inclusion of one HTML stream into another works by cloning the
to-be-included stream's title cell. When a clone is encountered in the
vstream, the HTML server looks for the original and reads the vstream on
d.2, along with the first markup stream attatched on d.markup, if the
structparams attatched to the clone don't specify another (or none)
markup stream to be used.

Yes, the clones shall have structparams, so that we can use the same
mechanism for templates. However, connecting these params on d.1 would
be overcrowding and confusing, as we use d.1 for linking (which is more
often used and thus should be more easily accessible). Instead, let's
connect the dummy cell on d.3, with the normal d.2 rank hanging from
there.

A first, primitive version of templates could just be an ordinary HTML
vstream, with some cells meant to be replaced by something else. To
replace a cell by something else, clone it into the structparams for the
template clone, and next to it on d.1 put what you want in the cell
instead; this can be a single cell of text, or a clone of a HTML
vstream. When the HTML server interprets a cloned HTML vstream, it
searches the structparams for any cloned cells; for every cell in the
structparam list which is cloned, it searces an intersection with the
cloned HTML vstream; for every intersection it finds, it supplies what
is find on d.1 next to the cloned structparam.

Whaddya think?
- Benja