[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

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

> > Why don't we spec a minimal subset, implement it and publish it
> > somewhere (my list of publications needs some feeding ;) ;)
> What, do you think, is a minimal subset? I think we'd like to have:
> - arbitrary HTML tags
> --> would be nice if they'd be in a parallel tag structure, so that
> showing the text is easy
> - links in ZigZag structure which are automatically converted to HTML
> --> should be easy to visualize *all pages that link to this one* easily
> --> HTML target anchors should be supported (text-to-text instead of
> text-to-page link)
> - HTML templates, on the level of pages or parts of pages
> - scriptability: auto-generated pages or parts of pages (as a special
> case of templates)
> - links to scripted pages, passing along parameters
> - maybe links to images? I mean, of the non-breaking kind within the zz structure?

Yes, this is probably the ultimate list. But definitely not a minimal
subset ;)

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

The markup includes running text, style changes (code style and emphasis),
headings and images, which are figures which could eventually (and SHOULD)
be drawn using ZZ cells (all current figure editors suck).

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

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.

> > One thing I've been toying with is an UDP protocol for zz cells: TCP/IP is
> > slowed down because it deals with a stream where things have to be
> > received in time. With UDP we could send more data and then just resend
> > the dropped packets when requested. The client would always display what
> > it could.
> Sounds reasonable. Any idea on when client/server will happen? Do you
> tend to do it with applets or with standalone clients? The latter would
> probably easier to program, but on the other hand the former integrates
> directly into today's browser pages.

Depends on what kind of client/server. There was a quick protocol at one
point but it's not currently functional. If it works on applets, it'll
work easily on standalone clients as well so that's not a problem (or is
it: what kinds of net connections are the applets allowed to open?)

Client/server comes in many flavors:
The simplest would be a  1-directional client-server where one slice is
served remotely, read-only. Once we have slices, this will be easy.