<none>

Mike Prince mprince@crl.com
Mon, 5 Dec 1994 13:25:29 -0800 (PST)


Based on the votes I received; Myself, Fare, and an implicit one from 
Johan, here is our new charter.  The name is not finalized, but Joy is 
the front-runner.  Please contact me to have your name added to the 
member list, everyone is welcome.

Please in future messages, try to focus on revising this document with 
your new ideas.  We have had a blizzard of good ideas in the last month, 
but many have been "lost" from not being put to rest in a document.  I 
will make a concerted effort to do this in my postings, and will edit my 
replies to others to foster this.  In the end it will benefit us greatly.

Again, thank you to everyone for sticking with this project and 
contributing the feedback which made this charter possible.

Mike 



Joy Charter
=========================================

1. This project shall be called "Joy"
	and its members shall be:
		Mike Prince (project 1-5 coordinator)
		Francois Rene Rideau 
		Johan van Schalkwyk
		<add your name here...>

2. This project shall be governed by a set of rules, organized hierarchically. 
	2.1 Conflicting rules: rules with lower numbers take precedence 
		over rules with higher numbers (and rules over 
		sub-rules).
	2.2 A rule may be added/removed/modified by; 
		2.2.1 a successful VOTE (as outlined in Rule 5) 
		2.2.2 the PROJECT COORDINATOR
	2.3 In referring to a rule, accepted names may replace numbers
		(e.g. 13.3  might become MOOSE.WOMBATS).

3. A PROJECT is a rule containing:
	3.1 the name of a PROJECT COORDINATOR
	3.2 A list of MEMBERS
	3.3 A list of sub-rules 

4. The project coordinator is responsible for adequate documentation of
	that project, including its list of rules.

5. Voting procedure
	5.1 Message is posted to "VOTE" with that project, containing:
		5.1.1 rule to be revised/deleted/added;
		5.1.2 proposer;
		5.1.3 expiry date by which votes must be in;
		5.1.4 project coordinator (to whom you post your votes);
		5.1.5 new rule text (if needed).
	5.2 Minimum period of one week must elapse, during which members
		post YES, NO, or SPOILED votes to the project coordinator;
		5.2.1 At least one-fourth of the members in projects
			affected by the rule must cast votes for the vote
			to be valid.
	5.3 Within 48 hrs of expiry date, coordinator posts results of vote.
		5.3.1 Rules pass by 2/3 or more of cast votes. 

6. Goals
========
	The following is a list of goals for our project;

	6.1 must be a friendly intuitive UI
	6.2 must have a lot of productivity apps (mail, wp, spreadsheet, 
		ie necessary apps)
	6.3 must fill a strategic niche (i.e. choose our customers well)
	6.4 must be malleable (no set ui, easy to personalize)
		It is great to have a flexible system, but, let's face it, 
		most people are creatures of habit. Present John Citizen 
		with more than several options, and he will more likely than 
		not crack wide open! Have a set UI that is so damn good that 
		no one in his right mind would want to change it and then 
		make it so easy to change that even Windows users can adapt 
		it to suit their perverted needs!
	6.5 use all the available resources (over net too)
	6.6 all the above must remain constant over all platforms (who 
		cares what hardware they are using).  My app here runs on all 
		my platforms.  No multiple shrinkwrap copies.
	6.7 must have a good development environment
	6.8 must be able to use all available resources (look above too)
	6.9 persistency  
		Considered to be part of the user friendliness 
		thing.  Not only is the ui the same, but the apps and all 
		objects in the system are exactly the way you left them.
	6.10 separate mechanism from policy
	6.11 support standards where feasible
	6.12 simple, portable strategies
	6.13 include marketable things, not gee whiz features
	6.14 Maintain identity of each interacting "organism" 
		(ie. don't splurge things out all over so you don't know 
		whether you're Arthur, Martha, or HAL)
	6.15 Do NOT do elsewhere what you can do locally
	6.16 Keep it straight and simple (KISS). 
		Apply Occam's razor ruthlessly.
	6.17 Organization of diverse talents
		Turn our major weakness (lack of ability to organise) into 
		a strength.  Is there a general purpose system, disseminated 
		in time and space, that can in a user-friendly and perfectly 
		general, object-oriented way, allow organisation of diverse
		talents, with permanence etc? No. Not yet. But this is 
		surely what we want to create! So let's create it, and then 
		USE it, refine it, and sell it! If we can't do this, we will 
		surely fail, and if we can, we may just have our "niche". 
		Perhaps we could design into it as an extremely simple
		"point and shoot" hypertext system (that even I could use).
	6.18 A low-level goal. Ruthlessly eradicate redundant instructions. 
	6.19 Establish the identity of the individual user. 
		Treat him as an individual, and respect that he is using 
		the system as his own personal TOOL. People enjoy feedback, 
		especially warm positive feedback. Even build a simple
		personality (as simple as Parry without the paranoid 
		ideation!) into the OS, and win the heart and mind of the 
		user. Turn the OS into a combination of an expert assistant 
		and a waiter in a high-class restaurant!! And, above all, 
		respect the intelligence of the user!! If the system makes 
		a fuck up, let it apologise! Treat the user as a human being, 
		not as a simple minded dickhead who really should know that 
		depressing SHIFT+Q with your left hand and CTRL+ALT+Z with 
		your right while pressing the N key firmly with your nose 
		is the only recognized way of indenting the paragraph!
	6.20 Be able to use a distributed network of processors.
		6.20.1 coherency - is what I see what you see, 
			at the same time?
		6.20.2 reliability - how certain am I that I am not 
			getting garbage?
		6.20.3 time - is my time your time?
		6.20.4 causality
		6.20.5 efficiency
	6.21 Unify error detection _and_ correction and allow graceful failure.
	6.22 Approach problems holistically

7. Glossary
===========
	This project is coordinated by Mike Prince.
	
	The glossary is unavailable by ftp at this time.

8. Survey
==========
	This project is coordinated by Mike Prince.
	
	The following have been evaluated as to their ability to satisfy 
	our goals as set forth in Section 6.

8.1 Microkernels
-----------------
	8.1.1 Amoeba
	8.1.2 Mach
	8.1.3 SpringOS

8.2 Operating Systems/Environments
-----------------------------------
	8.2.1 UNIX
	8.2.2 NextStep
	8.2.3 Taligent
	8.2.4 ANDF (OSF)

8.3 Languages
--------------
	8.3.1 Forth
	8.3.2 C++
	8.3.3 Scheme
	8.3.4 Hermes

9. Distribution Language
========================
	This project is coordinated by Mike Prince
	
	Development of a minimal low level "symbolic assembly language" and 
	simultaneous creation of higher level stack based interpreted 
	language.

	9.1 Goals
		9.1.1 Absolute simplicity 
			minimal code. Core code of <= 20 lines!
		9.1.2 Designed for fast interpretation or efficient
			compilation
		9.1.3 compatability
			9.1.3.1 POSIX
			9.1.3.2 i386
	9.2 Specifications
		9.2.1 Word size?
		9.2.2 Data types, especially iro communication of 
			information between objects.
		9.2.3 Basic notation/evaluation
			Polish, Reverse Polish, Infix ...?
		9.2.4 CRCs on a low level from the start?
		9.2.5 Message format
		9.2.6 Semantics
		9.2.7 local memory management 
			9.2.7.1 persistence
			9.2.7.2 garbage collection
			9.2.7.3 security

10. High Level Language
=======================
	This project is coordinated by Francois-Rene Rideau. 

	10.1 Goals
	10.2 Specifications
		10.2.1 typing semantics
	     
11. Distribution
================
	This project is coordinated by Francois-Rene Rideau. 

	11.1 communication protocol
	11.2 scheduling
	11.3 security/recovery
	11.3 distributed memory management 
		11.3.1 persistence
		11.3.2 garbage collection
		11.3.3 security

12. Documentation
=================
	This project is coordinated by Francois-Rene Rideau. 

	12.1 documentation format & conventions
	12.2 documentation tools
	12.3 comparison with other system software

13. User Interface
==================
	This project is coordinated by Mike Prince.  
	
	13.1 basic abstractions
	13.2 integration to high-level/distribution language
	13.3 automatic adaptation to terminal capability
	13.4 layout manager