From: jud@Athena.MIT.EDU
Message-Id: <9202142233.AA27734@ithake.MIT.EDU>
To: musedesign@Athena.MIT.EDU, aspoerrie@Athena.MIT.EDU
Subject: Minutes
Date: Fri, 14 Feb 92 17:33:07 EST

Here is my version of Tuesday's minutes.  Additions or corrections are welcome.

						Jud

		*	*	*	*	*	*

Design Meeting
Thursday, 14 February
Minutes

A General Brainstorming Session:

1) Do we want to support multiple operating systems and multiple windowing
systems?

	Two approaches to supporting multiple OSs and WSs:
	
	1)  Define the platforms we want to support, determine the
	greatest common denominator of their functionality, and
	build upon that subset.

	2)  Establish a reference design and implementation, but
	plan the design with a view to easy migration to other platforms.
	One variant of this plan: establish a base platform and specific
	secondary platforms.  Determine advocates for each secondary
	platform.  Run all design issues past the advocates.  If they
	don't like something, they can negotiate that part of the
	design.  Depends on having knowledgeable and effective
	advocates.

	Meeting favored the second approach.  Primary platform
	will probably be vanilla UNIX and X.  Other components
	still need to be specified.  Secondary platforms:
	Mach multiprocessor systems, MS-Windows, Mac OS and
	Toolbox.

	Interesting suggestion: partitioning functionality into
	different modules that could potentially run as separate
	processes given OS support.  For example, separating
	all windowing and interface issues from all processing.

2) What is Muse?  Is it primarily
	a) a language or set of languages,
	b) a runtime environment = executable program,
	c) an authoring environment including editors and object
		library, or
	d) a media server.

	(d) is new.  The Muse concept of media has been simple enough
	that we have never had to give much thought to how Muse
	accesses and distinguishes different units of media data.
	We have delegated much of that function to Galatea.  But
	in a digital realm, this will become more complicated and
	more important.

	The meeting felt Muse was first an application description
	language or languages and secondly, and authoring environment.
	Much more thought needed on this.

3) What should the Muse language(s) be like?  Ideas:
	a) Everything as an object, 1 language, objects have resources
	similar to X or Mac resources, all objects come with default
	resources.

	b) Packages as objects that inherit defaults.  Could be
	implemented by default constructors.  Supports the
	notion of templates.

	c) Do we need the DDL as ASCII or should it be stored in a binary
	format that would require good editors.
	Meeting came out fairly forcefully in favor of keeping the ASCII
	form, while not ruling out a more compact binary form.
		1) ASCII as an aid to debugging.
		2) ASCII is more portable.
		3) How do you create new template objects without
		a DDL?

	d) One object library or two?  One object library in the implementation
	language, say C++, used to build the Muse environment but potentially
	a multimedia toolkit reusable for other purposes.  A second
	written in an object oriented Muse language like EventScript,
	a reusable tool and template library.

4) Where should we go from here?  The meeting felt strongly that we
	needed a user generated functional spec before proceeding
	much further with design.

		*	*	*	*	*	*

	Responding to (4), three people have agreed to prepare brief draft
documents addressing a particular aspect of the functional spec.  The
drafters will hold meetings or otherwise solicit team members' input.
Drafters are:
	) Evelyn for user issues: interface, editors, application
		program structure
	) Lynne on market issues: what is Muse's constituency and competition?
		What must Muse do to distinguish itself from competing
		products?  What platforms should we support?
	) Toshi on product issues: extensibility, portability and
		maintainability

	We hope to have draft reports by Tuesday, the 25th, although
we will postpone if it will take longer to gather the necessary
design input.  Drafters would present initial versions at a meeting
on the 25th.  A second meeting on Thursday, the 27th, would then
discuss the drafts.  After this general discussion, the unified spec
will probably be written by a small subcommittee and then recirculated for
comment and approval.