[gmpi] Re: Where are we?: 7.1.2/'Profiles' definition premature
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 16 Jun 2003 20:11:31 -0700
I don't agree with some of the assumptions being made about what a
profile could/should/must be -- such limits are premature. It
completely remains to be seen whether a profile (...presuming there'd
be any...) would include other things beyond sample data type (for
example, profiles -could- also be a way to manage/bound multichannel
audio formats [presuming there'd be any]. Differences in code
packaging [presuming there'd be any] -could- also be an aspect of a
profile.). A profile might include that kind of stuff, or might not,
but there's zero need to decide that at this point. And proceeding
on the mere assumption that a profile is no more than a data type
seems very unwise because we would be risking building a chain of
subsequent design decisions on a misapprehension. (Not to mention
doing a reducto ad absurdum on the general idea of profiles.)
All we need to do for now is keep in mind that -IF- the requirements
collection process tells us that GMPI as a whole needs to offer more
options than a given use area (like DAWs, or MP3 playback, or, or,
or...) needs or wants to support -- whatever those option sets turn
out to be by the time we finish the specs -- then something like
profiles -might- be a way to keep the segments separated...
...Bearing in mind that all of that is if-and-only-if we as a group
decide we -do- want to keep them separated. We don't know that yet.
There are some assumptions being held about that at the moment, which
is a big part of what derailed the discussion last week. One
position (per Tim) is that it's important to keep the segments
together; that IMHO is purely arbitrary position, and there's been
plenty of argumentation for the opposite conclusion. There is
currently no group agreement that keeping the segments together is a
requirement, and proceeding down a logic chain based on the
assumption that such a requirement exists is not at this point
justified. Some of the arguments against profiles used in that chain
(to bring this post full circle) use dubious assumptions about what a
profile is.
As a group, we need to unpack some assumptions and get back to
collecting requirements information. I'll post something in a couple
minutes that I hope might help us get unstuck.
-- Chris G.
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
- References:
- [gmpi] Re: Where are we?: 7.1.2
- From: Tim Hockin
- [gmpi] Re: Where are we?: 7.1.2
- From: Jeff McClintock
Other related posts:
- » [gmpi] Re: Where are we?: 7.1.2/'Profiles' definition premature
- [gmpi] Re: Where are we?: 7.1.2
- From: Tim Hockin
- [gmpi] Re: Where are we?: 7.1.2
- From: Jeff McClintock