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

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

> And killer app in MY humbly opinion: A servlet encapsulating the gZZ
> structure, serving HTML pages generated from a to-be-determined zz
> substructure, plus programmability by some cellular language (even
> though CLANG is way off, we'll have *my* programming system soon; the
> two should be compatible).

A servlet is one possibility; being a full HTTP server is another. I'm
almost leaning towards the latter, running another webserver on the side
for static content.

> Editing HTML in *true structure*:
> -- being able to follow links back (at editing time)
> -- no broken internal links
> -- removing a page also removes links to that page, automatically
> -- build-in rich visualizations of site structure, not bound to hierarchies

Sounds like a good way of showing "normal people" a glimpse of what ZZ has
to give. Why don't we spec a minimal subset, implement it and publish it
somewhere (my list of publications needs some feeding ;) ;)

> I think this is something many people would jump upon. Finally we may
> want to transcend the web: but this is on the same level as your file
> browser or zzshell, showing zz's capabilities while maintaining the old
> structures for some time, until people have migrated to zz. Also could
> be used as a Xanadu-to-HTML converter when ZZ supports U.Green (xu88),
> but people haven't Xanadu software yet.

Yes, and it also ties in with Ted's idea of the dual http://... xu://...
space, where a xanadu URL can be used to access the richer content from a
ZZ client. Being able to show people "here you see a table, now let's
switch mode, and browse it and the links much more interactively, they get
loaded to the cache as fast as the protocol can...". Nice.

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.