Re: [zzdev] Killer Apps (was How ?

[inSECT22 <i22@xxxxxxx>]

[21.07.2000 ° 23:58 Uhr] Ted Nelson -->

-| Killer Apps IMHO--
-| ? file browser
-| ? "zzshell"-- encapsulation of commands to simplify *ix commands
some high level syntax for dealing with cell manipulation + display?

-| ? explorable 2000-year chronology, including various historical
-|  events and one's own appointments and personal history (I'm
-|  working on this)
why the arbitary 2000 yr christian timeframe?+

-| ? family tree WITH ADDRESSES AND PHONE NUMBERS of
generic contact database thing

-| Others I can't think of at the moment

 ? the "text"(flob) editor 
 
 ? the everything to everything conect-o-matic (conect-o-tron?)
 
 ? mail (pop/imap/stmp) reader/storage/sender/x-ref/anotater/ etc.
  
ive thougth a bit about how a mail feature could work, or arrange the data.  (since i couldnt get the ZZmbox example to execute) ,.  and email seems to be some of the most common intertwingled stuff most people have lying around on their computers ,. . here are some random thoughts about organisation inside (g)zz. -raises a few questions, especially with regard to many<->one linking which would be common for email (as i see it) and probably leaves just as many unasked as unanswered .,. 

possible implmentation/hacks-_  unfortunately i havent really had a chance to try coding any of this with java zz, (but there is a dusty version using zigzag.pm,.)  it could be possible to incorporate aspects of the grendel code (since it seems to have been designed with some separation of the mailing code + db code) ) or build a zz module around the javamail lib from sun.  

the essential idea is that the zz structure can be used to store alot of info about the email implicity, so reading mail or searching thru mail becomes much easier + more obvious(?) than with current programs., 
there are possibly much better ways of doing this using scrolls or flobs or spans within scrolls, which i would definately apreciate hearing /thinking about,. however all this stuff is based on the cell as a basic unit.,  . .
 
anyway ->


basic dimensions
 (extracted from emails)
    +d.msg          - contains entire message, 
                      header+body+etc (attatchments?) 
    +d.subject      - list of subjects 
    +d.eddress      - list of email addresses 
    +d.to  
    +d.from  
    +d.cc
    +d.date_sent    
    +d.id           - message id (unique) 
    +d.body         - message body only
    +d.atch         - atatchment if any
    +d.unread       - unread flag
   (+d.X-header. ..)  perhaps
   
subspace dimensions   
    +d.thread       - messages with same subjects or in-reply-to:
                       (cell d.subject as headcell)
    +d.filter       - user defined dimensions/mailboxes list
                       (contains names of dimensions (headcells?))
                       
intial mbox state is a single cell (HOME?/mbx?) circularly linked to itself along each of the required directions. 
messages are then inserted/deleted along apropriate dimensions. 
 
adresses,subjects
since there can be multiple messages with same subject/to/from etc, there has to be a way to arrange + easily access messages without using many<->one linking (since this is not an intristic part of the zz structure. could use secondary re3f (ie pointers) but this oneway structure could be dangerous if cell numbering is not persistent and unique - would also cause probs with dereferencing/deletion + cleanup)

to/from-> 
the d.eddress contains all unique eddresses each in a single cell, message cells are then inserted d.(to|from)wards from the cell containing the sender/receivers eddress 
how to handle d.cc ?+

(multiple eddresses for one person can be deal with by linking eddress cells along d.person, d.alias or something)
 
unique subjects are entered (alphabetically?) along d.subject. 

message cells are inserted along d.thread from the subject cells 
(more complex threading should be looked into,. many responses and/or threads from single msg) single messages may also appear in severl threads (how is this displayed?) 

messages can be grouped into boxes/threads/groups with user defined rules (similar to mail filters) the names of which are cells along d.filter 
messages are then linked along d.<whatever-name-filter-thing> 
filters: pattern matchign (grep/regexp?) on contents of cells  results in a series of cell insertion/deletion operations. 
requires simpl (easly understood in terms of zz cells)  syntax. 

<<< single message linking if required/desired >> 
<<any message may be linked to any other message by linking along a generated dimension that is a hash of the src + destination message ids (must be a unique value, since many messages may be linkd to/from) etc. >>


message display/retrieval_ __
a mailbox or view would be a (probably multidimensionl) slice or chunk (intersection) of zz space.,. views would be the result of a traversal along a single dimension (most recent by date) or a combination of 2 or more (eg. filtered mail threaded by subject)  
most of this could be displayed with standard mailreading style layout.
more zz specific would be views which showdd the msg related to current message (by to/from/subject/filtr/date/etc) ) thus making relevant mail more readily accesable. cells can be created for annotations/labels that so often occur when reading mail.  thus ->
- mail more integrated into othr std. ops 
- more easily/  accesed from notes/texts etc,. 
- mail more oftn used for 'storing' thoughts/x-refs/ code snippets  etc.

this brings up an intresting point about what exactly an "app" is (would be)  in zz.
an application is seen currently as a monolithic programm with a single task + set of subtasks. it has a well defined boundry of function, in order to do something else (even minor things outside the 'task'), another application (and all its supposedly useful subtask set)  must be opened. this is true for most WIMP systems currently existing,. 
a documentcentric view allows additional functionality to be added gradually, or as required, there have been a few 'failed' attempts at this (most notably from apple). zigzga seem heavily 'document' centric from within the current doc/app framework. 
since everything is represented in the same consistent underlying structure, any additional 'functionality' or celluar organisation provided by an 'app' should be available to the rest of the existing structure and thus existing 'documents' (cellular constructs). 
i presume most apps in the zz context would be one, or more, of 3 types
 - presenting existing cells to the user
 - modifying the zz structure
 - interacting with the non-zz world 
an email app would cover all these aspects 
(ui, structural organisation + interaction with remote non-zz systems)  


</babble_mode>