From: harada@Athena.MIT.EDU
Date: Thu, 27 Feb 92 10:06:21 -0500
Message-Id: <9202271506.AA02050@hastur.MIT.EDU>
To: musedesign@Athena.MIT.EDU
Subject: adgenda for my talk

Good monring,

Included is an agenda for my talk today, "Muse II
portability, extensibility, and maintainability
requirements from an industrial partner's view". (it's long...)

Since I have already distributed it to the attendance of
the last MUSE II meeting held on Tuesday,
this mail is for who those who missed that meeting.
(and those who lost it.)

One of the (?) nice things with my dgenda is it's written in
simple ASCII text like DDL or EventScript is. ;-)
So, print it whatever way you like...


				--- Toshi (^.^)
---8<---8<---


		Portability, Maintainability, Extensibility of MUSE

			--- industrial partner's view ---


1. Review of MUSE I

1. 1. Let the codes explain what is MUSE...

  drwx------  2 russ         2048 Feb  4 11:07 Displays
  drwx------  4 russ         2048 Apr 24  1991 EvScript
  drwx------  4 russ         2048 Jan 17 15:57 Galatea
  -rw-------  1 jud           628 Apr 24  1991 Makefile
  drwx------  3 russ         4096 Feb  4 11:05 Packages
  drwxr-xr-x  2 jud          4096 Sep 20 17:42 Tools
  drwx------  2 russ         2048 Jan 17 15:50 conf
  drwx------  2 russ         2048 Jan 17 15:57 include

$ wc -lwc Displays/*.[ch] Packages/*.[ch] include/*.[ch] | tail -1
   40241  110250  934856 total	# it's not very compact
$ wc Tools/*.[ch] | tail -1
   12298   33100  271698 total
$ wc Galatea/*.[ch] | tail -1
      27     208    1330 Galatea/copyright.h	# DOOH!
$ wc Galatea/*/*.[ch] | tail -1
    2266    6580   58771 total
$ egrep LIB Packages/Makefile
XLIBS = -lXaw -lXt -lXext -loldX -lXmu -lX11
LIBDIR = /usr/lib
LIBS =
LINK_CFLAGS = $(LDFLAGS) $(XLIBS) -lm
LINK_LIBS = ../Displays/libdsp.a ../EvScript/lib/libevscr.a
		../Galatea/Glib/libG.a
muse: $(OBJS) $(LINK_LIBS)
        $(CC) -o muse $(LOCAL_CFLAGS) $(GLOBAL_CFLAGS) $(OBJS) $(LINK_LIBS)
		$(LINK_CFLAGS)
        -rm -f $(BINS) $(LIBS) $(OBJS) core makelog lintfile *~
		../include/y.tab.h

2. 1. Portability of MUSE I

2. 1. 1. Dependence of MUSE I

Basically MUSE is (or should be) "portable", because it's written in C and
based on the standard X window system version 11, release 4.

However, in fact it's not portable because of dependence on:

	1) video board hardware (currently supported: 8bit depth)
	2) Galatea Video Server

The X server for our workstation is not an extended version
of the standard X server, but is a "subset" of it.  For instance,
there's no way to display multi-byte characters in the display.
(still can we call it X?)

2. 1. 2. Porting Status to SPARC

Who Did It:
	Yoko, Jud and Toshi

What They Did:
	o modified options for "ld" to do static link (for EventScript)
	o modified the library specification to suit SPARC
	o "shrunk" some applications to fit SPARC display resolution
	  by a shrink editor
	o ported Galatea

What They Found:
	o enhanced version of Openwin is far from stable
	o public software is cheap, but with no warranty)

Final (Current) Porting Status:
	o ported version of MUSE is working pretty faster on SPARC
	o difference in color depth messes up "pixmap" display on SPARC
	  (might be a peculiar problem to Parallax "Video View" board)
	o still have problems with porting of Galatea
	  (it can't work without Yoko's weird patch)
	o "shrink editor" is not perfect and human hands are always
	  expected for dirty jobs

2. 2. Maintainability of MUSE I

Actually we are maintaining two different versions of MUSE, one is for
DEC VAX and the other is for IBM RT.  Thanks to Jud, we don't have two
complete sets, and the amount of codes has been minimized.

Each set of codes has been managed with the aid of RCS program.

So no serious problems can be seen in maintainability of MUSE I.

2. 3. Extensibility of MUSE I

In principle, MUSE is extensible because it's written in C.

However, the interface to do that is not quite organized.
For example, we have to recompile a huge amount of codes
to provide a new functionality to MUSE. (Embedded MUSE?)

3. MUSE II as a runtime environment

3. 1. What Should We Expect for Portability of MUSE II

3. 1. 1. Categories of Portability

(1) Source Code

Minor differences such as "X11 R3 and R4" can be absorbed by using
"#ifdef"s without serious problems, however, trying to cover
every kinds of differences including OS is ugly and sometimes impossible.

List of Possible Dependence:

o operating system
	{BSD*, SysV*}, MS-DOS, OS/2, {Mach, Chorus}, Mac etc.
o window system
	X, Windows, Mac etc.
o user-interface (not an independent issue, though)
	widgets, proprietary tools like NeXTStep, etc.
o RPC
	SUN, HP, COBRA...
o video board
	Parallax, RasterOps etc.
o media server, in particular for "motion video" media resource
	Galatea, create our own
o database
	should be discussed later...
o C (Can the language really affect the system?)
	C, ANSI C, C++2.1, C++3.0 etc.

(2) Scripting Language (not an independent issue, though)

portable ...  adapt other existing languages (ex. HyperTalk)
in-between ... have language(s) in ascii text and leave possibilities
proprietary ...  invent own data structure which allow efficient access

(3) Executable

No way...

(4) Protocols

Invent protocols for multimedia application execution and construct
MUSE II on them.  (Possible kinds of protocols will be shown later)

(5) Screen Display

o Display PostScript
o SRGP (after hearing Stuart's talk, I'm not very serious with this)

3. 2. What Should We Expect for Maintainability of MUSE II

If our human resources afford, no problem.

3. 3. What Should We Expect for Extensibility of MUSE II

o providing methods to extend a system without recompiling everything
  is preferable (dynamic loading may help, but not available for
  every platforms)

4. What Do We Actually Have?

It's worth thinking because we are not supposed to create
new operating system, window system or workstation.

(1) Platform

o SUN SPARC IPC, IPX (coming soon)
o Omron Luna88K (hopefully)
o OKIDATA i860
o NeXT NeXTCube

(2) Video Board

o RasterOps, 24bit depth for SPARC
o NeXTDimension, 24bit depth for NeXT (might be available)
o Parallax, XVideo, 24bit depth available at least for SPARC

(3) Operating System

o SUN OS 4.1.1. ... for SPARCS, of course
o System 6.?, 7.? ... for Macs
o etc.

(4) Window System

o X11 R4
o X11 R5 (supposed to be bundled with one of SPARC)
o Openwin (SPARC bundled)

(5) RPC

o ONC/RPC is bundled with SPARC
o COBRA ... don't expect it will become available before MUSE II design fixed

(6) Window System Extension

o Should (or Can) we count on "VEX"?

5. NTT Data's Vision as an Industrial Partner

5. 1. Requirements

o Multi-byte language support (at least Japanese) is *DEFINITELY* needed
o SPARC must be included in platforms

5. 2. Visions for MUSE II

(1) MUSE as a high end authoring environment, in particular for
    UNIX workstation platforms.
(2) MUSE to propose standards for multimedia runtime/authoring system.
	--- model, language, protocol etc.
(3) MUSE as an explorer of new technologies and devices.
	--- packet switched video, digital audio etc.

6. OMRON's Vision as an Industrial Partner

Same as NTT Data's vision except OMRON would like to see MUSE II
on their hardware (Luna88K?).

7. To which direction should we go? (Toshi's personal view)

Possible directions for to which should we head (inside parenthesis
are specific issues to MUSE II):

o Keep adding new media resources
	(compressed image, digital audio, MIDI...)
	# these are good things to do

o Propose a standard language to express multimedia applications
	(extend the concept of "dimension") or
	(invent a new concept which will replace MUSE dimension)
	# I believe "dimension" is the essence of MUSE I

o Propose a model for multimedia authoring/runtime environment
	(close all functionalities in one executable and provide
	 interface to them for scripting language) or
	(design all-in-one type huge environment)
	---
	(compiler type vs. interpreter type)

o Propose standard protocols for multimedia application
	(between interpreter and media resources) or
	(between interpreter and display... hurray virtual display!)
	# sounds good but not very feasible

o Increase portability
	(insert new layer between the interpreter and physical media resources)
	# I can't think of any other idea

o Enlarge the range of platforms
	(Windows, X11 R5, Mac etc.)
	(SPARC, NeXT, Mac etc.)
	# our resource is not infinite

o Introducing new technology
	(collaborated multimedia)
	(distributed multimedia)
	(database interface)
	(packet switched video)
	(adapt object-oriented for each media resource)
	(multi-thread support)
	# certain vision is required for each of above