Goals Summary

[Mike Prince]

11/9/94 Mike Prince <mprince@crl.com>

I have compiled all the goals people have set forth over the last week.
I apologize if I have left anyone out, if so please re-send them
directly to me and I will add them to the list.  This post is an
attempt at organizing our goals.  I have broken them into;
	
	End Users/Marketing/Goals
	Programmers/Marketing/Goals
	Methods
	General

Why are we here?  If we are here to make something useful for the rest
of humanity, then we should first focus on the End Users and
Programmers "Goals".  Once the goals are established we can see if our 
pet methods will be part of the "solution".

As was pointed out earlier, if our egos get in the way, then our efforts 
will result in a mismatch of well developed technologies.  Not the best 
use of our time.

The General goals should be the least disputed section.  So no more will
be said about that.

And now the Methods...  This is where our research comes in, egos get hurt,
and we can test out our voting system.  So lets delay even touching this
until we have established our End User/Programmer Goals sections.

So for the next few days let's focus on what end-users would want.  We can
address niche markets (I'd like our OS to fit in my wristwatch/cell phone 
and act like a personal secretary to screen my calls) or the big ones.

Let's just brainstorm, I'll add any/all ideas to the following goals list.
No questions asked.  Next week we can start to prune our goals and focus
on a development project.

I look forward to hearing more goals,

Mike


Contributors
=============
KH: Kyle Hayes
AT:  Andy Thornton
GD: Gary Duzan
JMA: Jecel Mattos de Assumpcao Jr.
MG: Matt Garrett
MP: Mike Prince
RM: Raul Deluth Miller
JVS: Johan Van Schalkwyk

End Users/Marketing/Goals
===========================
JVS: On the top level an intuitive and user-friendly interface.
JVS: A wide variety of really good applications must be available to
	run on it
GD: A basic set of user applications: word processor, spreadsheet,
	drawing tool, etc.
JVS: Identify certain key components without which no-one will want to 
	use the system. 
JVS: We must position it in the market so that it occupies clear
	"niches" or has well-demarcated attributes that make it
	desirable (People must want to use it because it does
	certain things that are not readily available on current
	systems)
JVS: I think that it would also be advisable to identify certain
	strategic "niche" applications that one can create, positioning
	them so that one can later bridge these to create a more
	omprehensve system.
JVS: It must be readily identifiable
JVS: We must carefully identify those areas where:
	a. there is a need, and
	b. we have expertise
	and exploit these to their full potential.
JVS: Identify our "overall strategy" and then choose a name for the
	project that is consistent with that strategy
JVS: Good design that really works for the end user!
MG: No set UI. Let the individual users choose what kind of
	interface they want and go with it. Also, make the UIs as
	hardware independent as possible.
MG: Software engines that remain constant from platform to platform
	I'd like to know that I'll be able to read the same documents,
	play the same sounds, and view the same graphics on any platform
	and not have to learn new software on each.
MG: Network transparent resource sharing. If I'm chugging away on a
	CPU intensive app and the computer next to me is idle, I want
	to be able to ask that computer to help me out (if the two 
	machines are networked, of course).

Programmers/Marketing/Goals
===========================
JVS: New applications must be easily developed / imported from other
	systems
MG: To be able to use all the hardware to the optimum and not be
	regulated by what the systems programmer is capable of
	providing me with.
GD: A good development environment.

Methods
=======
MP: Persistent computing (machine wakes up where it left off)
RM: Machine abstraction suitable for handling system resources
GD: Have system capabilities available for all nodes
MP: Migration of code while the processor is executing it
RM: Persistent computing; computation recovers after loss of computing
	elements.
RM: Intermediate level langauge, "below main-stream programming",
	suitable for rapid compilation to a variety of microprocessors,
	machine abstraction suitable for describing system capabilities
AT: a framework in which to place our objects
KH: OO all the way down.  Polymorphism is your friend.  Whether it is
	done in some nifty language like Self or in a kind of kludge 
	like X-Windows widgets, I don't really care.  My ego is not on
	the line about what language we use _as_ _long_ _as_ _it_ _does_
	_not_ _constrain_ _us_!  I would like to see garbage collection
	support deep into the language and system.  I have yet to see an
	argument against garbage collection that I can't refute with a
	few references to papers.  I also want to see support for
	persistence.  I think that persistent object stores can
	replace file systems eventually in a more flexible way.
KH: datagram-style message passing at a very low level,
KH: distribution supported at a fairly high level (language or
	 system),
GD: Emphasis placed on client-server environments
KH: platform independence.  Make a reasonable attempt to avoid things
	that would make MOOSE TUNES incapable of running on most
	platforms.  If we use transputer messaging or x86 segments,
	we will not be able to easily port code to other platforms that
	don't have these "features".  I think that it is worth
	sacrificing a lot of performance in order to achieve a high
	level of hardware independence.  You can always performance tune
	things later.  First let's design with hardware independence
	in mind.  For all that I can't stand Micro$oft, their HAL layer
	in NT is not a bad idea.  I think that the definition of such
	a layer would be a good thing to look at _after_ we have made
	some decisions about the other goals.
KH: distribution, but don't go overboard.  Distribution is poorly
	understood at best.  After a couple of months of research I
	have found that there are few or none who can even approach
	distributed systems in any serious analytical way without
	making such drastic simplifications that their models are
	almost useless.  Distribution and parallelism are often
	highly related.  Rather than trying to make the perfect
	distributed system on a first go, I would much rather see an
	approach that allows all kinds of distribution models to be
	tried.  This kind of goal can be met in large part by close
	adherence to the second goal above.  Allow systems to talk to
	each other, but do not enforce a single kind of interaction.
	Go with the kinds of mechanisms that do not preclude the use
	of higher level protocols.  For instance, a lot can be built
	on a datagram model of distributed messaging.  I want to see
	object migration possible under MOOSE TUNES.  This is a
	very powerful concept and should be looked at closely.  If we
	play our cards correctly with the object model and platform
	independence stuff, I think we can make it so that object
	migration does not need low level support and can be handled
	on the system or language level.  Provide a mechanism for
	object migration and it can be used by automatic load
	balancing code or directly by users themselves.  Let the higher
	levels handle policy.

General
=======
KH:  support standards _where feasible_.  I don't expect to be able
	to take the ELF binaries off my Sparc and run them under TUNES
	tomorrow.  However, it would be nice if TUNES machines could
	at least support socket connections from the outside world,
	deal with some UNIX-style security issues etc.  It would be nice
	if I could have a TUNES system do some talking to a "standard"
	network.  I am not asking to be able to run my binaries, just
	that there is some support for working with such older systems.
	If that means that we need to write UNIX/PC/MAC-side support
	routines to allow us to use TUNES from such a platform, that
	will just make TUNES more palatable.
KH: separate mechanism and policy from the first instant and at every
	level,
KH: research, research, research; no new wheels please.
KH: wheels were invented a long time ago, let's not to reinvent them.
	Truly new ideas are surprisingly rare.  All the research I
	have done indicates that 99.9% of supposedly new ideas were
	written up several years ago and tested.  I will send a
	bibliography after this message.  I encourage people to read
	this stuff.  I always learn new things and see new problems.
	Some of the seemingly simple solutions I have seen posted here
	have hidden catches that you might only find after doing
	exhaustive testing.
JVS: Tight explicit coding, with simple strategies that are readily
	portable
KH: mechanism not policy.  Provide mechanism at the low level and let
	policy be decided by higher level entities. E.g. provide a way
	to switch tasks, but allow difference schedulers to be used.
	Provide a way to send messages, but do not force a single way
	of using them.  This is the microkernel way, but can be applied
	to any level in the system.
JVS: It must sell well.