:Larry Bonham, Xerox Corporation
Dennis E. Hamilton, InfoNuovo
Hitoshi Tanaka, Hitachi Corporation, Ltd.
Version 0.02 - 2000-02-24 Minor cleanup for inclusion on the web site. The section is still highly incomplete. It is provided for completeness and as a basis for further work as part of the DMware open-source clearinghouse activity. This is the first version publicly distributed.
Version 0.01 - 1999-06-09 Original proposal draft by Dennis Hamilton with most architecture-proposal sections still left as boilerplate.
Content
1. Functional Overview / Description
2. New/Changed Data Types and Values
3. New/Changed Classes and Properties
4. New/Changed Interfaces
5. Architectural Impacts
6. Reference Materials
7. Existing Systems and Related Experiences
8. Compliance and Conformance Considerations
9. Sample Usage
10. Glossary / Nomenclature
11. Impact on Existing Systems
12. Performance Considerations
13. Backwards Compatibility and Legacy Considerations
14. Incorporation Into DMA Specifications
15. Implementation and Deployment
Support for MNCS Extensions are specified in two separate proposals. The first proposal describes the impact on the binary interfaces standardized by DMA. That determines all of the additional interfaces and the string formats that are used with the additional interfaces. The first proposal is complete unto itself and is all that is required to implement the MNCS extension.
The second proposal provides programming support for creation of string-format independent programs that can be built to operate with one MNCS string-format or another simply by changing some macro definitions. Some recommended macros and their usage are defined in "DMA Architecture Proposal for MNCS String Manipulation Library." The use of the MNCS Library is entirely optional. It is implemented and provided so that developers can use a portable, common solution readily available to all of the DMA community.
A new DMAString Data type is introduced: DmaString_A. This datatype provides for character strings that consist of counted sequences of 8-bit (octet) character-string elements.
The principle of operation of DmaString_A is the same as DmaString, except for octets instead of for 16-bit character string elements. (Technically, DmaString is the DmaString_B format, but the _B suffix is never used in DMA.)
The new data type is introduced in the usual forms,
pDmaString_A,
ppDmaString_A,
and so on. Basically, every DmaString form already defined is supplemented by an additional DmaString_A form.
There are also additional character set encodings, many that are specific to DmaString_A usage. These additional character set encoding names and numbers are
Include table of new character-set encoding names and their codes here.
For convenience in programming, there is also a generic character-string data type, DmaString_T. This is provided in the DMA interface definitions and supporting files and is used when the program is designed to operate with any one of DmaString_A, DmaString, or any additional character string formats that may be introduced using the same principles. The discussion of DmaString_T and other macros used to simplify portability of programs between multinational string formats is discussed in a companion sketch. It is kept separate because it is important to distinguish what impacts DMA interfaces and what is simply an accommodation for the source program and having no impact on the proper interfacing between DMA-integrated components.
The DmaString_T is not an actual data type that is ever seen at a DMA interface or delivered to a method. DmaString_T is a "macro" that will at any time actually be implemented by DmaString_A, DmaString, or another string format.
Consider whether any new result codes need to be defined for failure to obtain the right kind of character string support from a supplied object or any binding problems related to inconsistency in character string support.
not applicable
For MNCS, there are two kinds of interface changes: additions to the integration-model interfaces and replication of standard DMA 1.0 COM interfaces.
We need to extract out a definition (included in the glossary section) for what it means for two objects to be MNCS-compatible.
- It is delivered from a particular MNCS interface form.
- All interfaces that it supports are supported in that MNCS form
- It accepts interfaces of that MNCS form on any objects that are delivered to it via an interface parameter to a method.
The IUnknown, IMalloc, and similar interfaces that have no DmaString parameters to their methods, are automatically accepted as being all of the MNCS forms.
It is conceivable that an object could support more than one MNCS string format, but it would require that the prevailing character set encoding be equally representable in the multiple formats. Objects are permitted to support more than one MNCS format, they are simply never required to do so.
The DMA System Manager connection interface dmaConnectSystemManager_A is added to the defined interfaces for connecting a system manager.
The only difference in the signature of dmaConnectSystemManager_A form dmaConnectSystemManager_A is using pDmaString_A wherever pDmaString is used in the original interface.
When an application connects to the System Manager using the default interface, no objects delivered under that system manager instance, directly or indirectly, need provide anything but default interfaces. In addition, providing objects that do not honor the default interfaces as parameters to default-interface methods may be rejected.
Likewise, when an application connects to the System Manager using an alternative MNCS interface, no objects delivered under that system manager, directly or indirectly, need provide anything but the particular MNCS interfaces. In addition, providing objects that do not honor the established MNCS interface family as parameters to MNCS-interface methods may be rejected.
The integration entry for connecting service objects are supplemented by matching interface having suffix "_A." E.g,,
DMA_GetServiceObject_A is added.
Again, the only difference between _A signatures and the default signatures is the use of pDmaString_A wherever pDmaString is used in the default interfaces.
When a default interface is employed for activation of a service object, that object and any objects it delivers need only support the default string format. In addition, receiving objects that do not honor the default interfaces as parameters of the services default-interface methods may be rejected as bad parameters.
When an alternative MNCS interface is employed for activation of a service object, the resulting object and any objects it delivers need only support the specified alternative MNCS interfaces. Again, incompatible objects supplied as parameters to methods may be rejected as bad parameters.
This wording is used because we anticipate expansion of the default interfaces to support aggregation and possibly other integration functions.
Any time that there is an extension or addition to the Integration interfaces of DMA, the introduction of a new default interface is automatically accompanied by an "_A" version of the same interface.
When a default interface does not have any DmaString parameters of any form, it is not necessary to introduce a new "_A" version. To simplify programming and ensure consistent practice, an "_A" version will also be defined, but the "_A" name will be realized by a macro definition to the default name.
The IdmaServiceRegistry Interfaces are never required to provide any visibility whatsoever on registry entries that were introduced using a different MNCS string format than the prevailing one.
When an object is integrated under one MNCS string format, it will only be instantiated with that MNCS string format. To register an object as supporting more than one MNCS string format, it must be registered with the appropriate style of IdmaServiceRegistry interface.
A system manager is not required to support a combination of MNCS and character set encoding for which it is not prepared to register objects and then invoke those objects. (That is, the system manager does not have to register objects it may have no way to invoke using the underlying operating system platform.)
Proposal: An IdmaServiceRegistry interface is not required to deliver strings recorded in a character set encoding other than the one now prevailing. That is, an IdmaServiceRegistry can completely hide entries for objects that cannot be instantiated with the current MNCS and character set encoding. Likewise, it does not have to accept registrations for objects which operate in a different character set encoding than the one that now prevails. These provisions enforce the rule that strings delivered across an interface are always in the prevailing character set encoding and never anything else. In particular, an IdmaServiceRegistry interface is permitted to refuse to deliver strings submitted in a different character set encoding to a requester operating with a different prevailing character set encoding (and MNCS format).
This is basically the standard idea of suffixing all the interfaces.
One important rule: If an interface definition has an understood character set encoding (e.g., ones from ActiveX), it is expected that the interface will not be available at all for incompatible MNCS or prevailing character set encoding.
The architectural impact of the MNCS Extension is primarily in the Integration Model and in Internationalization / Localization.
5.1 Integration Model
5.2 Query
5.3 Internationalization/Localization
5.4 Content
5.5 Containment
5.6 Versioning
5.7 Security
5.8 Naming
5.9 Requirements Addressed
5.10 Failure Modes / Crash Recovery
created 1999-06-09-11:39 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 00-02-24 16:39 $
$$Revision: 3 $