[$XConsortium: issues.mif /main/3 1996/08/28 15:33:57 ray $]
The following is the issues list for the X A system. This list is somewhat outdated now - refer to the front of the
protocol specification for major open issues. For example, the chapter number below are wrong. However, with
the project cancelled, there is no point in updating this list.
Entries have the following header fields:
issue_number, area, chapter [level1header[.level2header]] - description
So, for example, the entry
is issue 5, in the protocol specification (P), Chapter 4, Buffer section, supportedFormats subsection, with a short
ened description of "how is this described?".
For each issue, a longer description follows usually with a (hyperlinked) cross-reference to the appropriate, and
discussion will be added at a later time.
- 5 P4 Buffer.supportedFormats - how is this described?
- "...attribute expresses the formats supported by this object" We need a description of how. See "supported
Formats" on page 11 of the protocol specification.
- 6 P4 Buffer.gain - standard volume
- "The gain attribute expresses the amount of amplification to produce a signal of standard volume." We need a
definition of standard volume. See "gain" on page 11 of the protocol specification.
- 7 P4 Buffer.gain - representation
- "Gain is expressed in signed 16.16 notation in decibels, where 3dB represents a doubling in power, and 6dB
is a doubling in amplitude. (0 corresponds to unity.)" Is this the right expression of gain? Type descriptions?
See "gain" on page 11 of the protocol specification.
- 8 P4 Buffer.inputBuffer - direction
- Should we reintroduce a direction attribute that is settable at create time? Would that make things easier or
harder to understand?
- Since we now have a "findObject" request, the direction attribute is useful, and ought to exist on buffer or
port.
- 11 P4 Device.jacks - speaker selection
- How to express jacks, speakers, etc., is still up in the air. See "Device Class" on page 12 of the protocol spec
ification.
- 12 P4 Device.volatileSize - one or two volatile zones?
- Is there a second volatile zone on the other end of the buffer, since data transfer is typically not continuous,
but occurs in bursts? See "volatileSize" on page 12 of the protocol specification.
- 14 P4 Server.extensions - scanning for new extensions
- "The extensions attribute contains the extensions (loaded and unloaded) currently available in the server." We
need a mechanism to cause this list to be reloaded. We could do it every time a get is done, but that might be
too heavyweight. Suggestions? See "extensions" on page 20 of the protocol specification.
- 15 P4 Server.resourceDatabase - preference model
- What or whether this is depends on the how we deal with preferences. See "resourceDatabase" on page 21 of
the protocol specification.
- .17 P4 Connection.destroyOnClose - untrusted clients never permanent
- "The destroyOnClose attribute determines whether the server destroys a client's objects when the server
detects that the client has severed the connection. The destroyOnClose attribute value is ignored for an
untrusted client - its objects are always destroyed on the close." Is this the right thing to do? See "destroyOn
Close" on page 21 of the protocol specification.
- .22 P5 Predefined Buckets - do we need a system beep?
- "The server will predefine one or more buckets. At a minimum, there will be a "system beep" bucket pre
defined." Is this a requirement? See "Buckets" on page 28 of the protocol specification.
- .27 P5 Buckets - how is system beep replaced?
- "This sound may be replaced by trusted clients" How? See "Buckets" on page 28 of the protocol specifica
tion.
- 28 P5 Buckets - finding predefined
- How? -probably as an attribute on the server object, or as a named object? See "Buckets" on page 28 of the
protocol specification.
- ray@x.org - Tentatively added a "buckets" attribute to the server object in the specification. Comments?
- 31 P9 Audio Management - details needed.
- Need major work here... See "Audio Management" on page 34 of the protocol specification.
- 32 P11 Read Request - description missing.
- 36 P10 Parsing - XaPtype - need valid conversions.
- Need list of valid conversions! See "XaPtype" on page 39 of the protocol specification.
- 37P10 Parsing - is a list parsing needed?
- Do we need a list parsing as well? See "Parsing Parameter Lists" on page 37 of the protocol specification.
- 38 P11 Find Atom - define reply
- Need to define reply. See "Find Atom Request" on page 40 of the protocol specification.
- 40 P11 Write Request - need details on request parameters
- Need detail on write request parameters. See "Write Request" on page 43 of the protocol specification.
- 43 P13 Encoding write - encoding of left pad
- The encoding of leftPad needs to be thought about. It is really a card 8, but for alignment and byte swapping
reasons is easier to make a CARD32. This wastes space. We could stuff it in the unused field of the header,
although that removes the possibility of using that field globally in the future (and has slight impact on swap
ping?). We'll worry about this later. See "XaWrite" on page 52 of the protocol specification.
- 44 P13 Encoding - errors on non-zero padding?
- "Protocol senders must set all unused fields and padding in the protocol stream must to zero, with the excep
tion of the data portions of write requests and read replies. The receiver is not required to check unused fields
and padding for compliance." Should we insist that the receiver not generate errors? See "Overview" on
page 47 of the protocol specification.
- 1 P3 - attribute name prefixes
- The specification needs to be explicit whether these prefixes are transmitted as part of the protocol or not. If
not, then it really becomes a library/user documentation issue. See "Naming conventions" on page 8 of the
protocol specification.
- The "Xa" prefixes do not belong as part of the atoms used in the protocol.
- 2 P4 Core.classID - inheritance
- Is the inheritance chain in the classID attribute, in some sort of a class description object, or a parent
attribute? We recently split tags into tags and atoms - how this affect this? See "classID" on page 10 of the
protocol specification.
- 3 P12 Events - describe model
- See "Events and Errors" on page 45 of the protocol specification.
- Events are now defined. See the above reference for details.
- 4 P4 Core.name - tag or string
- Is this a tag or string object? See "name" on page 10 of the protocol specification.
- 9 P4 Buffer.access - default value
- "The access attribute is the tag of an access object that determines what untrusted clients may access this
buffer. When a buffer is created, the access tag is copied from the creating connection." This includes objects
created by the server - they get it from the master connection??? See "access" on page 12 of the protocol
specification.
- 10 P4 Buffer.access - precedence of Connection.access
- "The value of the connection's access attribute does not affect a buffer whose access attribute is not set to
XaTnone." Is that what we want? See "access" on page 12 of the protocol specification.
- 13 P4 Bucket, Waveform - playback pitch/tempo
- The mechanism for play back at other than the native pitch/tempo is not defined yet. See "Bucket Class" on
page 13 of the protocol specification. See "Waveform Class" on page 13 of the protocol specification.
- 16 P4 Connection - do we need key
- We ought to be able to find out what key this client was authenticated with, so that we can kill other connec
tions that used the same key as an unruly client. Does this supercede the trusted field? Maybe. Depends on
implications of destroying a key that is in use. See "Connection Class" on page 21 of the protocol specifica
tion.
- We've moved towards security groups, so things have changed substantially. We do want the key field, so that
we can tell what credentials were used by this client to gain access.
- 18 P4 Connection.suspended - right way to handle access queries?
- "The suspended attribute is set to true on an untrusted client if it has made an unauthorized access that
resulted in a query. The attribute can only be modified by a trusted client." This is ugly - any better ideas? See
"suspended" on page 22 of the protocol specification.
- We dropped query-on-access-attempt from the core audio protocol. This would most likely appear in a sepa
rate security protocol, if ever.
- 19 P4 Connection.objects - not very scalable?
- "The objects attribute contains a collection of tags that include all objects created for this connection." This
isn't very scalable. - events on this could get quite large if many objects are created. Also, unless we put fil
ters in triggers, it could generate a lot of noise if we're only interested in a few of the creates. See "objects" on
page 22 of the protocol specification.
- The objects attribute has been dropped - applications can use the findObject request to find the current
objects, and use a conditional monitor to for events on the creation of new objects.
- 20 P4 Connection.extensionsInUse - success of loading extension?
- "A client adds an extension to this list to announce to the server that it intends to use this extension". Is there
an easy way to tell if this succeeds? See "extensionsInUse" on page 22 of the protocol specification.
- 21 P4 Access.accessQuery - what event back to security manager?
- "The accessQuery attribute is used when an untrusted client attempts to access an object for which it does not
have access rights. If it is contained in the collection of connection tags in the accessQuery attribute, the
untrusted client is suspended" And somehow an event is generated to the security manager? See
"accessQuery" on page 24 of the protocol specification.
- We dropped query-on-access-attempt from the core audio protocol. This would most likely appear in a sepa
rate secuirty protocol, if ever.
- 23 P4 String - do we need these?
- We probably need some sort of object that represent strings. We could use atoms for these, but the string asso
ciated with an atom can not change, and atoms have a very long lifetime. This needs more thought. Ideas
please? See "String Class???" on page 25 of the protocol specification.
- 24 P4 Extension - opening extension protocols
- "If an extension defines new protocol requests or events, the library (or application) must open a separate pro
tocol on the ICE connection." How does this protocol relate to the client object? Does opening the protocol
add this extension to the client's extensionsInUse attribute? See "Extension Class" on page 25 of the protocol
specification.
- 25 P4 Class - do we need class objects?
- It would be nice to have some way to find out what the attributes are defined for a given class. And maybe
what types are acceptable. (Of then you'd want an object that describes what values are legal for that type,
and so on. It's a mighty slippery slope. Steep too.) OTOH the class object could be useful for setting defaults,
if it could also function as a template. Depends some on how we architect preferences and the audio manager
interaction. See "Class Class" on page 26 of the protocol specification.
- We'll have them, as descriptions. They provide a place to monitor for object creation. also, they are very use
ful for a debugger.
- 26 P4 Class - tag vs. atom in create request?
- The recent split of tags into atoms and tags makes it so that the tag for the class object is not the same as the
atom that the class was created with. This is ugly. See "Class Class" on page 26 of the protocol specification.
- Use the atom in the create request - We allow for well-known (predefined) atom tags, but not object tags.
- 29 P8 Security.access - is the access granularity right?
- Are buffers and connections the right granularity of access control? See "Selective Access" on page 32 of the
protocol specification.
- The access attribute has been moved from the buffer class to the core class.
- 30 P8 Security - how to protect some server objects?
- How do we deal with server-defined formats and other objects. Some we want as accessReadOnly for all cli
ents, others as accessReadWrite for trusted clients, and some as accessReadWrite by everyone... So are server
created objects handled specially, or do we create some special "hidden" access attribute? See "Selective
Access" on page 32 of the protocol specification.
- We now have per-object access granularity.
- 33 P10 Tags - XaTnone - does it have a class?
- "The tag 0 is preallocated for XaTnone." Does XaTnone have a class?. See "Tags and Atoms" on page 36 of
the protocol specification.
- XaTnone is just a reserved tag, and has no class.
- 34 P11 Find Tag - is string encoding right?
- Is STRING8 and "should use the ISO Latin-1 encoding" the right decision? See "Selective Access" on
page 32 of the protocol specification.
- 35 P10 Parsing XaParray, XaParrayPart - define multidimensional array ordering
- Need ordering of elements in multidimensional arrays. See "XaParray parsing" on page 37 of the protocol
specification. See "XaParrayPart" on page 38 of the protocol specification.
- 39 P11 Destroy - define destruction while in use rules.
- Need to define what happens if the object is referenced by other object when it is destroyed. Options seems to
be replace it with some default, don't destroy while still referenced (and provide method to find who's refer
encing it), generate errors on all of the referencing objects, or generate an error the next time the non-existing
object is used. Suggestions? Ways to avoid implementation nightmares? See "Destroy Request" on page 42
of the protocol specification.
- We have a proposal for object lifetimes based on references. It has not yet been incorporated into the specifi
cation, but no other alternatives have been presented.
- 41 P13 Encoding Item Types - 8 byte alignment of items?
- Do we need to 8-byte align and pad items? This would help extensions with 8-byte fields, but wastes bytes.
Requests, of course will be 8 byte padded, due to ICE. See "Item Types" on page 47 of the protocol specifica
tion.
- 42 P13 Encoding XaParray, XaParrayPart - define encoding of nested arrays
- Need to define rules. See "XaParray" on page 48 of the protocol specification. See "XaParrayPart" on
page 48 of the protocol specification.
- 45 P4 Connection.access - new access object for each connection?
- Should an access object be created by default for each new connection, to make change all of its access
(including buffers) easier to change later in its life? See "access" on page 22 of the protocol specification.
- 46 P4 Waveform - clients locating
- Should we add a waveforms attribute to the server class, or lump them in with input buffers or buckets? See
"Waveform Class" on page 13 of the protocol specification.
End Of Document