zz: "Front and back ends (Was: ZZDEV Problems

[Ted Nelson <ted@xxxxxxxxxx>]

Hi gang--

This talk of front & back ends sounds very fine to me.
 This is basically the direction I've had in mind.

The idea is that ZigZag is a rational and consistent structure
 for anything-- a new operating system (at least, at the conceptual level)
 where a user doesn't have to think (in principle) about files,
 hierarchy or the usual traditions-- but can build great stuff
 with rational structure always visible underneath, if you want
 to open the box.

Will try to find time to detail more of these designs.

Best, Ted


At 12:41 PM 4/18/99 -0700, you wrote:
>Sorry for the delay here, I've been unexpectedly busy.
>
>At 02:51 PM 4/7/99 +0100, you wrote:
>>> >>The second point I'd like to make is that it IMO we've gotten to the
>point
>>> >>where we need to break zigzag.pm into seperate pieces.
>>
>>I'm not sure zigzag.pm is too large.  the script and the module were
>>only recently 
>>separated and I think some artifacts remain (the script still opens the
>>database?)
>>
>>I'd really like to see the front and back ends separated from each other
>>by a network connection.  The back end is the ZigZag server written in
>>perl and the front end is something else somewhere else.  Here we get a
>>collabarative enviroment and a client cabable of using the hosts display
>>cababilities to the full.
>
>This is mostly what I had in mind; the size issue is more a reflection of
>a) my personal programming esthetics and b) that I wasn't very familiar
>with the current version. The seperation of front end and back is the real
>key, esp if we're going to supportthe program on more than one platform.
>The FE-BE seperation is a key part of the final Xanadu system, for the same
>reason (among others).
>
>>The problem with all of this is that Andrew is already maxed-out trying
>>to implement the squillions of ideas that he and Ted have worked out
>>already. Maybe ZZ version 2?
>
>Perhaps. What I was looking for in the short term was just a physical
>seperation of the interface code into a seperate package file, which is a
>lot simpler than a full-fledged client-server design. What may make the
>most sense is if I work out a simple prototype on a seperate RCS worldline
>(is that the right term?), with no (or very few) changes in program
>behavior, just separating the UI code out. 
>
>>> >Sorry for being gone for so long, but other matters have been getting in
>>> >the way. After my talk with Marlene, I had promised to try and work on
the
>>> >prototype Windows 95/98 installation package, and I should be free to
>do so
>>
>>yey! another windows user! - this post get's windowsey from here on...
>
>Not exactly by choice. I'm no fan of *any* of the existing OSes, but I've
>mostly used Multics95 for work-related reasons.
>
>>> >For now, I'm using ActivePerl 1.0 (build 509), which is supposed to be BC
>>> >with Sarathy's port. Since its under the Community Liscense, it
supposedly
>>
>>I had bad experiences a while back with ActivePerl.  I found the
>>Gurusamy build a lot easier to use and more compatible with the Unix
>>version. The trouble is - Gurusamy now works for Activestate so I guess
>>we'd better start using their build.  I hope he's made it better.
>
>It seems OK, but it doesn't appear to have a Curses module the way I
>understand Sarathy's did. As a result, I haven't gotten it working yet.
>Worse, I can't seem to find one for it. It looks as if it may be necessary
>to use Win32:Console instead, which means we'd need two radically diferent
>versions of the screen handling code. I could go back and install an older
>version, but then we'd have support and updating problems. Are there any
>other suggestions? 
>
>>> >First off, when we're ready to do so, I assume we'll want a
>self-installing
>>> >system a la InstallShield. In order to do this, I'll need to know what
>>> >we'll be bundling together with the program. For example, will we want to
>>> >have it autoinstall Perl (or offer the option to do so), or should we
>>> >assume that the user has already installed it (or can install it
>later)? In
>>
>>tricky question.  Most Unix users are familier with installing extra
>>librarys in order to get something to work (or they know a guru that
>>can).
>>
>>Most windows users will not have perl installed or know what CPAN is. 
>>Is it possible to take just bits of the ActiveState package and
>>re-package them?  If so then could you make an install that contains
>>eveything that you need to make ZigZag run?  This makes things easy for
>>the user and gives you control of which version of perl / shared
>>library's are installed - it might make for a bigger install but how big
>>was your system directory last time you looked?
>
>It looks like it. They distribute the Perl interpreter seperately, and it
>should be possible to bundle just the interpreter and the libraries, but
>I'm not sure. They also offer a Perl compiler, but its not free, and I
>don't know if all of the current code would work compiled (it should, I
>haven't seen any reflective interpreter calls or other problematic code,
>but I haven't gone through the code exhaustively yet).
>
>
>J Osako
>Programmer Analyst, Operating Systems Designer, Notational Engineer
>http://www.slip.net/~scholr/resume.html
>
>
____________________________________________________
Theodor Holm Nelson, Project Professor,
 Keio University SFC Campus, Fujisawa, Japan
 Home Fax from USA: 011-81-466-46-7368  (If in Japan, 0466-46-7368)
http://www.sfc.keio.ac.jp/~ted/  (Professorial page)
_____________________________________________________
Permanent: Project Xanadu, 3020 Bridgeway #295, Sausalito CA 94965
 Tel. 415/ 331-4422, fax 415/332-0136  
http://www.xanadu.net (see also Professorial page, above)
PERMANENT E-MAIL: ted@xxxxxxxxxx
_____________________________________________________
"Underneath our clothes, we are all naked."  TN~64