From: Allan Schaffer (allan++at++sgi.com)
Date: 12/14/2000 22:38:45
info-performer,
Just wanted to let everyone know that activity is starting up over on
the new info-performer-dev++at++oss.sgi.com mailing list. If you're
interested in participating in (or listening in with) the Performer
Open Development Project, please refer to:
http://oss.sgi.com/projects/performer
To subscribe, see:
http://oss.sgi.com/projects/performer/mailing.html
Thanks,
Allan
ps. We'll try not to make a habit of 'cross-posting' info between
info-performer & info-performer-dev; they have very different
purposes. Please send any replies regarding the message appended
below to the new list.
--- Forwarded mail from Allan Schaffer <allan++at++sgi.com>
Date: Thu, 14 Dec 2000 18:55:50 -0800 (PST)
From: Allan Schaffer <allan++at++sgi.com>
To: info-performer-dev++at++oss.sgi.com
Subject: Welcome to info-performer-dev
Greetings all,
The OpenGL Performer "Open Development" Project is officially
underway, let's kick off this new mailing list.
Source code for libpfdu, libpfutil, libpfui, the database loaders of
libpfdb, the sample applications, and programming guide samples are
all open to modification, addition, and redesign; new applications or
new libraries are welcome also.
Let's start off by hearing from you about:
- What you would like to see here on this mailing list
- What are your wish-list items to be added as far as:
. utility library functionality
. sample applications
. programming guide examples
- What your interests are in the context of this project
A bit about development philosophy: With Performer being such a
mature product and having an established application base, in most
cases we seek to minimize API changes, so as to minimize the porting
effort from one major release to the next. New functionality tends
to be introduced as internal additions to existing APIs, or in
completely new APIs, leaving the previously existing methods
unchanged. Our users have indicated that they appreciate this
approach.
This results in the (sometimes less than ideal) situation of having
multiple competing suites of similar functionality -- take our event
handling & UI code for example. I see a lot of this getting cleaned
up for Performer 2.5. It's important for the 'old' functionality to
remain, but it can be retired into secondary libraries as has been
done before. The corollary to this method is that new functionality
can & should be treated as first-class fully maintained code.
To sync up with what is happening internally: now that Performer 2.4
is released we are collecting and investigating suggestions &
requirements for Performer 2.5.
Simultaneously we are implementing bugfixes on the 2.4 stream for an
update release, Performer 2.4.1. Backwards _and_ forwards binary
compatible Performer updates ship with IRIX roughly each quarter.
In most cases, this project will effect the libraries & examples that
will ship with Performer 2.5. There may be cases where modifications
suggested here can be 'ported back' to 2.4 but they will happen on a
case-by-case basis.
That's all for now, let's hear from you..
Allan
---End of forwarded mail from Allan Schaffer <allan++at++sgi.com>
-- Allan Schaffer allan++at++sgi.com Silicon Graphics http://reality.sgi.com/allan
This archive was generated by hypermail 2b29 : Thu Dec 14 2000 - 22:38:49 PST