📄 jtt-issues.html
字号:
<HTML><HEAD><TITLE>Java Telephony API Version 1.1 Open Issues</TITLE></HEAD><BODY><H1><CENTER>Java Telephony API Version 1.1 Open Issues</CENTER></H1><LI> Getting a Provider Object<OL><p> In JTAPI 1.1, the JtapiPeer class defines the point of contact between application and JTAPI implementation. However, access to this class in a Java client environment is not always easy to ensure short of installing the JtapiPeer instance on that client. <p> Clearly, the JtapiPeer as presented in JTAPI 1.1 is not a general solution to the problem of giving all types of applications and applets access to a JTAPI Provider.<p> A more general solution will be provided in the next release of JTAPI, while maintaining support for the existing JtapiPeer model. The current JtapiPeer class scheme is sufficient to support development of applications and implementations to JTAPI.</OL><LI> Document Detail<OL> The JTAPI 1.1 spec addresses two audiences, JTAPI application writers and JTAPI telephony server implementors. It must communicate information to both groups. In some instances, this results in excessive detail to one party or the other. In other instances, there seems to be no good way of communicating the detail required by one party. One particular instance of the latter problem is communicating the detailed semantics of Call.connect() to an implementation audience.<p> Call.connect() can return a Connection, whose destination Addresses may not be identified by the same string as used in the Call.connect() to identify the destination. This could be the result of some switch idosynchrosy, for instance. In such a situation, the implementation must maintain 'aliases' for a particular address to present a consistent view of Address references to the application.<p> This kind of detailed information, most often required by the JTAPI implementors is provided as much as possible in this specification. However, if any area of the spec is found ambiguous or lacking, please feel free to use the feedback section of this document to ask for more detailed assistance. Every reasonable effort will be made to address your questions.</OL><LI>Synchronization of Threads<OL>The JTAPI peer implementation can (and probably will) have its own threadsof execution, separate from application threads. Thus, provisions must bemade for synchronizing changes to the data structures which are sharedbetween the application and the peer, that is, the call model objects.At the event observer level, the reports of individual changes to the callmodel are bundled together into indivisible meta-events. Peer updates tothe call model are synchronized with delivery of these meta-events to theevent observers. Thus, the observers always see the call model in anconsistent state.No such synchronization is available in JTAPI 1.1 for non-observerapplication threads. Applications which examine the call model objectsusing methods such as getStatus() and getConnections() may receiveinconsistent information, due to simultaneous changes to the objects by thepeer.</OL><H1><CENTER>Java Telephony API Version 1.0 Issues (CLOSED) </CENTER></H1><p><LI> Naming: There are numerous naming issues that we would like to resolve byJTAPI 1.1.<OL>There are numerous naming issues that we would like to resolve byJTAPI 1.1.We have chosen some abbreviations for event class names. We are abmivalentover the choice of 'Set' as the name for physical devices. In general,there may be some effort to improve naming by 1.1, at which point thosechoices will freeze.</OL><LI> Macro Events<OL>There are some sequence of events, which to an application might betterbe represented as a single event. This is particularly so for transfer and conference, which as sequences of events may be difficult to interpret by applications that may not have the full context needed to resolve thosesequences.</OL><LI>Capabilities:<OL>A capabilities package is under construction. It allows applications toquery whether they can place a telephone call, answer a telephone call, ordrop a telephone call. We still need to do a fair amount of work here.</OL><LI>Package Structure:<OL>There remain some questions of package structure. Though much of the structureis agreed upon and settled, some subtle changes may take place. For instance,the java.telephony.callcenter package may become java.telephony.callcontrol.callcenterand some of the capabilities may migrate to be more closely associated withtheir associated packages.</OL>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -