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

Re: [zzdev] Re: [zzdev] Killer Apps (was How ?

>  ? mail (pop/imap/stmp) reader/storage/sender/x-ref/anotater/ etc.

This is the one I've long thought to be THE thing: email and discussion
forums are the places where most people first encounter too much
complexity and volume that we could help with.
> 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.,  . .

We have something working in the Java version - see Modules/mbox. It reads
an mbox format file to the structure.

The structural format is a little different, using less dimension but the
basic idea is the same. The point is to try and make a flob display of it
as soon as possible. THAT view would be the killer.

> 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)  

And because the ZZ structure is such clean Model-View-Controller stuff,
then these three split apart very well, unlike in usual programming.