You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@openoffice.apache.org by wa...@apache.org on 2020/11/02 20:35:52 UTC
[openoffice-org] 02/02: Migration of udk html content
This is an automated email from the ASF dual-hosted git repository.
wave pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/openoffice-org.git
commit 9cf78a819f549e34de2577d6841e7fd64abbce75
Author: Dave Fisher <da...@davefisher.tech>
AuthorDate: Mon Nov 2 12:35:17 2020 -0800
Migration of udk html content
---
content/udk/basic/index.html | 90 +
content/udk/cli/cli-uno.html | 12 +
content/udk/common/man/apicppclasses.html | 161 +
content/udk/common/man/binspec.html | 421 +
content/udk/common/man/bridge.html | 11 +
content/udk/common/man/componentmodel.html | 178 +
content/udk/common/man/componentnames.html | 184 +
.../common/man/concept/default_bootstrapping.html | 12 +
.../udk/common/man/concept/micro_deployment.html | 344 +
content/udk/common/man/concept/streams.html | 772 ++
content/udk/common/man/concept/string_invest.html | 12 +
content/udk/common/man/concept/uno_contexts.html | 830 ++
content/udk/common/man/concept/uno_corba.html | 1014 ++
.../man/concept/uno_default_bootstrapping.html | 12 +
content/udk/common/man/concept/uno_langbind.html | 181 +
content/udk/common/man/concept/uno_security.html | 675 ++
content/udk/common/man/concept/unointro.html | 12 +
.../udk/common/man/draft/library_unloading.html | 14 +
.../udk/common/man/draft/scripting/BindingUI.html | 172 +
.../man/draft/scripting/DesignDoc/index.html | 453 +
.../common/man/draft/scripting/ProblemsIssues.html | 216 +
.../draft/scripting/Services-and-interfaces.html | 78 +
.../common/man/draft/scripting/ThreadingSoln.html | 265 +
.../common/man/draft/scripting/basic-storage.html | 310 +
.../common/man/draft/scripting/build-script.html | 296 +
content/udk/common/man/draft/scripting/index.html | 120 +
content/udk/common/man/idl.html | 673 ++
content/udk/common/man/idl_syntax.html | 534 +
content/udk/common/man/lifecycle.html | 308 +
content/udk/common/man/module_description.html | 309 +
content/udk/common/man/names.html | 11 +
.../udk/common/man/spec/assemblyversioning.html | 247 +
.../common/man/spec/assemblyversioninghistory.html | 131 +
content/udk/common/man/spec/com_lang_spec.htm | 12 +
.../udk/common/man/spec/connection_services.html | 115 +
content/udk/common/man/spec/library_unloading.html | 641 +
content/udk/common/man/spec/ole_bridge.html | 1262 ++
content/udk/common/man/spec/remotebridge.html | 285 +
.../man/spec/transparentofficecomponents.html | 319 +
content/udk/common/man/spec/uno-url.html | 116 +
content/udk/common/man/spec/urp.html | 13 +
content/udk/common/man/tasks/api_docu_review.html | 3247 +++++
content/udk/common/man/tasks/apitests.html | 169 +
content/udk/common/man/tasks/tasks.html | 12 +
content/udk/common/man/tools.html | 866 ++
.../udk/common/man/tutorial/office_automation.html | 333 +
.../udk/common/man/tutorial/uno_registries.html | 410 +
content/udk/common/man/tutorial/writerdemo.html | 166 +
content/udk/common/man/typenames.html | 298 +
content/udk/common/man/typesystem.html | 538 +
content/udk/common/man/uno.html | 223 +
content/udk/common/man/uno_components.html | 181 +
content/udk/common/man/uno_the_idea.html | 262 +
content/udk/cpp/man/component_tutorial.html | 401 +
content/udk/cpp/man/cpp_bridges.html | 1523 +++
.../cpp/man/draft/stacktraces_for_exceptions.html | 352 +
content/udk/cpp/man/spec/cpp_spec.html | 638 +
content/udk/cpp/man/spec/cuno_spec.html | 565 +
content/udk/cpp/man/spec/textconversion.html | 277 +
content/udk/cpp/man/spec/uris.html | 347 +
content/udk/cpp/man/tutorial/remotedemo.html | 153 +
content/udk/cpp/man/tutorial/unointro.html | 1258 ++
content/udk/cpp/ref/def-all.html | 12094 +++++++++++++++++++
content/udk/cpp/ref/help.html | 176 +
content/udk/cpp/ref/index-files/index-1.html | 394 +
content/udk/cpp/ref/index-files/index-10.html | 48 +
content/udk/cpp/ref/index-files/index-11.html | 48 +
content/udk/cpp/ref/index-files/index-12.html | 86 +
content/udk/cpp/ref/index-files/index-13.html | 402 +
content/udk/cpp/ref/index-files/index-14.html | 118 +
content/udk/cpp/ref/index-files/index-15.html | 1618 +++
content/udk/cpp/ref/index-files/index-16.html | 216 +
content/udk/cpp/ref/index-files/index-17.html | 332 +
content/udk/cpp/ref/index-files/index-18.html | 1390 +++
content/udk/cpp/ref/index-files/index-19.html | 606 +
content/udk/cpp/ref/index-files/index-2.html | 110 +
content/udk/cpp/ref/index-files/index-20.html | 326 +
content/udk/cpp/ref/index-files/index-21.html | 230 +
content/udk/cpp/ref/index-files/index-22.html | 88 +
content/udk/cpp/ref/index-files/index-23.html | 246 +
content/udk/cpp/ref/index-files/index-24.html | 44 +
content/udk/cpp/ref/index-files/index-25.html | 46 +
content/udk/cpp/ref/index-files/index-26.html | 40 +
content/udk/cpp/ref/index-files/index-27.html | 214 +
content/udk/cpp/ref/index-files/index-3.html | 340 +
content/udk/cpp/ref/index-files/index-4.html | 88 +
content/udk/cpp/ref/index-files/index-5.html | 236 +
content/udk/cpp/ref/index-files/index-6.html | 88 +
content/udk/cpp/ref/index-files/index-7.html | 890 ++
content/udk/cpp/ref/index-files/index-8.html | 72 +
content/udk/cpp/ref/index-files/index-9.html | 220 +
content/udk/cpp/ref/index.html | 50 +
content/udk/cpp/ref/names/Array/d.html | 47 +
content/udk/cpp/ref/names/Array/o.html | 39 +
content/udk/cpp/ref/names/JavaVMContext/d.html | 63 +
content/udk/cpp/ref/names/JavaVMContext/o.html | 239 +
.../JavaVMContext/t-UINT32_UINT32_HashMap.html | 48 +
content/udk/cpp/ref/names/RTConstValue/d.html | 65 +
content/udk/cpp/ref/names/RTConstValue/o.html | 121 +
content/udk/cpp/ref/names/RTConstValueUnion/d.html | 127 +
content/udk/cpp/ref/names/RTConstValueUnion/o.html | 39 +
content/udk/cpp/ref/names/RTUik/d.html | 79 +
content/udk/cpp/ref/names/RTUik/o.html | 39 +
content/udk/cpp/ref/names/Registry/d.html | 78 +
content/udk/cpp/ref/names/Registry/o.html | 1074 ++
content/udk/cpp/ref/names/RegistryKey/d.html | 65 +
content/udk/cpp/ref/names/RegistryKey/o.html | 1905 +++
content/udk/cpp/ref/names/RegistryKeyArray/d.html | 78 +
content/udk/cpp/ref/names/RegistryKeyArray/o.html | 324 +
content/udk/cpp/ref/names/RegistryKeyNames/d.html | 78 +
content/udk/cpp/ref/names/RegistryKeyNames/o.html | 324 +
content/udk/cpp/ref/names/RegistryLoader/d.html | 39 +
content/udk/cpp/ref/names/RegistryLoader/o.html | 121 +
.../udk/cpp/ref/names/RegistryTypeReader/d.html | 78 +
.../udk/cpp/ref/names/RegistryTypeReader/o.html | 1989 +++
.../cpp/ref/names/RegistryTypeReaderLoader/d.html | 39 +
.../cpp/ref/names/RegistryTypeReaderLoader/o.html | 121 +
.../cpp/ref/names/RegistryTypeReader_Api/d.html | 39 +
.../cpp/ref/names/RegistryTypeReader_Api/o.html | 39 +
.../udk/cpp/ref/names/RegistryTypeWriter/d.html | 78 +
.../udk/cpp/ref/names/RegistryTypeWriter/o.html | 1129 ++
.../cpp/ref/names/RegistryTypeWriterLoader/d.html | 39 +
.../cpp/ref/names/RegistryTypeWriterLoader/o.html | 121 +
.../cpp/ref/names/RegistryTypeWriter_Api/d.html | 39 +
.../cpp/ref/names/RegistryTypeWriter_Api/o.html | 39 +
content/udk/cpp/ref/names/RegistryValueList/d.html | 93 +
content/udk/cpp/ref/names/RegistryValueList/o.html | 292 +
content/udk/cpp/ref/names/Registry_Api/d.html | 39 +
content/udk/cpp/ref/names/Registry_Api/o.html | 39 +
content/udk/cpp/ref/names/__store_FindData/d.html | 122 +
content/udk/cpp/ref/names/__store_FindData/o.html | 39 +
content/udk/cpp/ref/names/_oslDateTime/d.html | 151 +
content/udk/cpp/ref/names/_oslDateTime/o.html | 39 +
content/udk/cpp/ref/names/_oslFileStatus/d.html | 188 +
content/udk/cpp/ref/names/_oslFileStatus/o.html | 39 +
content/udk/cpp/ref/names/_oslModule/d.html | 55 +
content/udk/cpp/ref/names/_oslModule/o.html | 39 +
content/udk/cpp/ref/names/_oslVolumeInfo/d.html | 170 +
content/udk/cpp/ref/names/_oslVolumeInfo/o.html | 39 +
content/udk/cpp/ref/names/_rtl_Locale/d.html | 95 +
content/udk/cpp/ref/names/_rtl_Locale/o.html | 39 +
content/udk/cpp/ref/names/_rtl_ModuleCount/d.html | 39 +
content/udk/cpp/ref/names/_rtl_ModuleCount/o.html | 39 +
.../cpp/ref/names/_rtl_StandardModuleCount/d.html | 63 +
.../cpp/ref/names/_rtl_StandardModuleCount/o.html | 39 +
content/udk/cpp/ref/names/_rtl_TestResult/d.html | 55 +
content/udk/cpp/ref/names/_rtl_TestResult/o.html | 39 +
.../cpp/ref/names/_rtl_TestResult_vtable/d.html | 175 +
.../cpp/ref/names/_rtl_TestResult_vtable/o.html | 39 +
.../udk/cpp/ref/names/_rtl_TextEncodingInfo/d.html | 145 +
.../udk/cpp/ref/names/_rtl_TextEncodingInfo/o.html | 39 +
content/udk/cpp/ref/names/_rtl_uString/d.html | 63 +
content/udk/cpp/ref/names/_rtl_uString/o.html | 39 +
content/udk/cpp/ref/names/_sal_Sequence/d.html | 81 +
content/udk/cpp/ref/names/_sal_Sequence/o.html | 39 +
.../ref/names/_typelib_ArrayTypeDescription/d.html | 95 +
.../ref/names/_typelib_ArrayTypeDescription/o.html | 39 +
.../ref/names/_typelib_CompoundMember_Init/d.html | 81 +
.../ref/names/_typelib_CompoundMember_Init/o.html | 39 +
.../names/_typelib_CompoundTypeDescription/d.html | 123 +
.../names/_typelib_CompoundTypeDescription/o.html | 39 +
.../ref/names/_typelib_EnumTypeDescription/d.html | 109 +
.../ref/names/_typelib_EnumTypeDescription/o.html | 39 +
.../names/_typelib_IndirectTypeDescription/d.html | 67 +
.../names/_typelib_IndirectTypeDescription/o.html | 39 +
.../d.html | 81 +
.../o.html | 39 +
.../_typelib_InterfaceMemberTypeDescription/d.html | 81 +
.../_typelib_InterfaceMemberTypeDescription/o.html | 39 +
.../_typelib_InterfaceMethodTypeDescription/d.html | 137 +
.../_typelib_InterfaceMethodTypeDescription/o.html | 39 +
.../names/_typelib_InterfaceTypeDescription/d.html | 180 +
.../names/_typelib_InterfaceTypeDescription/o.html | 39 +
.../cpp/ref/names/_typelib_MethodParameter/d.html | 97 +
.../cpp/ref/names/_typelib_MethodParameter/o.html | 39 +
.../cpp/ref/names/_typelib_Parameter_Init/d.html | 109 +
.../cpp/ref/names/_typelib_Parameter_Init/o.html | 39 +
.../cpp/ref/names/_typelib_TypeDescription/d.html | 212 +
.../cpp/ref/names/_typelib_TypeDescription/o.html | 39 +
.../names/_typelib_TypeDescriptionReference/d.html | 139 +
.../names/_typelib_TypeDescriptionReference/o.html | 39 +
content/udk/cpp/ref/names/_typelib_Uik/d.html | 79 +
content/udk/cpp/ref/names/_typelib_Uik/o.html | 39 +
.../ref/names/_typelib_UnionTypeDescription/d.html | 165 +
.../ref/names/_typelib_UnionTypeDescription/o.html | 39 +
.../udk/cpp/ref/names/_typelib_Union_Init/d.html | 81 +
.../udk/cpp/ref/names/_typelib_Union_Init/o.html | 39 +
content/udk/cpp/ref/names/_uno_Any/d.html | 83 +
content/udk/cpp/ref/names/_uno_Any/o.html | 39 +
content/udk/cpp/ref/names/_uno_Environment/d.html | 95 +
content/udk/cpp/ref/names/_uno_Environment/o.html | 39 +
.../udk/cpp/ref/names/_uno_ExtEnvironment/d.html | 53 +
.../udk/cpp/ref/names/_uno_ExtEnvironment/o.html | 39 +
content/udk/cpp/ref/names/_uno_Interface/d.html | 53 +
content/udk/cpp/ref/names/_uno_Interface/o.html | 39 +
content/udk/cpp/ref/names/_uno_Mapping/d.html | 53 +
content/udk/cpp/ref/names/_uno_Mapping/o.html | 39 +
content/udk/cpp/ref/names/c-Array.html | 100 +
content/udk/cpp/ref/names/c-JavaVMContext.html | 175 +
content/udk/cpp/ref/names/c-RTConstValue.html | 131 +
content/udk/cpp/ref/names/c-RTConstValueUnion.html | 133 +
content/udk/cpp/ref/names/c-RTUik.html | 120 +
content/udk/cpp/ref/names/c-Registry.html | 258 +
content/udk/cpp/ref/names/c-RegistryKey.html | 331 +
content/udk/cpp/ref/names/c-RegistryKeyArray.html | 183 +
content/udk/cpp/ref/names/c-RegistryKeyNames.html | 183 +
content/udk/cpp/ref/names/c-RegistryLoader.html | 123 +
.../udk/cpp/ref/names/c-RegistryTypeReader.html | 384 +
.../cpp/ref/names/c-RegistryTypeReaderLoader.html | 124 +
.../cpp/ref/names/c-RegistryTypeReader_Api.html | 78 +
.../udk/cpp/ref/names/c-RegistryTypeWriter.html | 244 +
.../cpp/ref/names/c-RegistryTypeWriterLoader.html | 124 +
.../cpp/ref/names/c-RegistryTypeWriter_Api.html | 78 +
content/udk/cpp/ref/names/c-RegistryValueList.html | 186 +
content/udk/cpp/ref/names/c-Registry_Api.html | 78 +
content/udk/cpp/ref/names/c-__store_FindData.html | 129 +
content/udk/cpp/ref/names/c-_oslDateTime.html | 135 +
content/udk/cpp/ref/names/c-_oslFileStatus.html | 155 +
content/udk/cpp/ref/names/c-_oslModule.html | 101 +
content/udk/cpp/ref/names/c-_oslVolumeInfo.html | 146 +
content/udk/cpp/ref/names/c-_rtl_Locale.html | 123 +
content/udk/cpp/ref/names/c-_rtl_ModuleCount.html | 98 +
.../cpp/ref/names/c-_rtl_StandardModuleCount.html | 113 +
content/udk/cpp/ref/names/c-_rtl_TestResult.html | 101 +
.../cpp/ref/names/c-_rtl_TestResult_vtable.html | 146 +
.../udk/cpp/ref/names/c-_rtl_TextEncodingInfo.html | 133 +
content/udk/cpp/ref/names/c-_rtl_uString.html | 110 +
content/udk/cpp/ref/names/c-_sal_Sequence.html | 116 +
.../ref/names/c-_typelib_ArrayTypeDescription.html | 120 +
.../ref/names/c-_typelib_CompoundMember_Init.html | 115 +
.../names/c-_typelib_CompoundTypeDescription.html | 130 +
.../ref/names/c-_typelib_EnumTypeDescription.html | 125 +
.../names/c-_typelib_IndirectTypeDescription.html | 110 +
..._typelib_InterfaceAttributeTypeDescription.html | 116 +
.../c-_typelib_InterfaceMemberTypeDescription.html | 116 +
.../c-_typelib_InterfaceMethodTypeDescription.html | 136 +
.../names/c-_typelib_InterfaceTypeDescription.html | 151 +
.../cpp/ref/names/c-_typelib_MethodParameter.html | 122 +
.../cpp/ref/names/c-_typelib_Parameter_Init.html | 125 +
.../cpp/ref/names/c-_typelib_TypeDescription.html | 162 +
.../names/c-_typelib_TypeDescriptionReference.html | 137 +
content/udk/cpp/ref/names/c-_typelib_Uik.html | 115 +
.../ref/names/c-_typelib_UnionTypeDescription.html | 145 +
.../udk/cpp/ref/names/c-_typelib_Union_Init.html | 115 +
content/udk/cpp/ref/names/c-_uno_Any.html | 114 +
content/udk/cpp/ref/names/c-_uno_Environment.html | 120 +
.../udk/cpp/ref/names/c-_uno_ExtEnvironment.html | 105 +
content/udk/cpp/ref/names/c-_uno_Interface.html | 105 +
content/udk/cpp/ref/names/c-_uno_Mapping.html | 105 +
content/udk/cpp/ref/names/c-remote_Connection.html | 67 +
content/udk/cpp/ref/names/c-remote_Context.html | 149 +
.../cpp/ref/names/c-remote_DisposingListener.html | 67 +
.../cpp/ref/names/c-remote_InstanceProvider.html | 93 +
content/udk/cpp/ref/names/c-remote_Interface.html | 98 +
content/udk/cpp/ref/names/c-remote_Mapping.html | 104 +
content/udk/cpp/ref/names/c-s_Anonymous__15.html | 104 +
content/udk/cpp/ref/names/c-s_Anonymous__20.html | 116 +
content/udk/cpp/ref/names/c-s_Anonymous__22.html | 101 +
content/udk/cpp/ref/names/c-uno_Context.html | 67 +
content/udk/cpp/ref/names/com/index.html | 64 +
content/udk/cpp/ref/names/com/sun/index.html | 64 +
content/udk/cpp/ref/names/com/sun/star/index.html | 64 +
.../udk/cpp/ref/names/com/sun/star/uno/Any/d.html | 39 +
.../udk/cpp/ref/names/com/sun/star/uno/Any/o.html | 1138 ++
.../names/com/sun/star/uno/BaseReference/d.html | 53 +
.../names/com/sun/star/uno/BaseReference/o.html | 416 +
.../ref/names/com/sun/star/uno/ContextLayer/d.html | 39 +
.../ref/names/com/sun/star/uno/ContextLayer/o.html | 184 +
.../ref/names/com/sun/star/uno/Environment/d.html | 53 +
.../ref/names/com/sun/star/uno/Environment/o.html | 541 +
.../cpp/ref/names/com/sun/star/uno/Mapping/d.html | 47 +
.../cpp/ref/names/com/sun/star/uno/Mapping/o.html | 1032 ++
.../ref/names/com/sun/star/uno/Reference/d.html | 39 +
.../ref/names/com/sun/star/uno/Reference/o.html | 1453 +++
.../cpp/ref/names/com/sun/star/uno/Sequence/d.html | 39 +
.../cpp/ref/names/com/sun/star/uno/Sequence/o.html | 970 ++
.../com/sun/star/uno/Sequence/t-ElementType.html | 53 +
.../udk/cpp/ref/names/com/sun/star/uno/Type/d.html | 39 +
.../udk/cpp/ref/names/com/sun/star/uno/Type/o.html | 938 ++
.../names/com/sun/star/uno/TypeDescription/d.html | 53 +
.../names/com/sun/star/uno/TypeDescription/o.html | 797 ++
.../names/com/sun/star/uno/WeakReference/d.html | 39 +
.../names/com/sun/star/uno/WeakReference/o.html | 184 +
.../com/sun/star/uno/WeakReferenceHelper/d.html | 39 +
.../com/sun/star/uno/WeakReferenceHelper/o.html | 505 +
.../udk/cpp/ref/names/com/sun/star/uno/c-Any.html | 254 +
.../names/com/sun/star/uno/c-BaseReference.html | 185 +
.../ref/names/com/sun/star/uno/c-ContextLayer.html | 122 +
.../ref/names/com/sun/star/uno/c-Environment.html | 204 +
.../cpp/ref/names/com/sun/star/uno/c-Mapping.html | 245 +
.../ref/names/com/sun/star/uno/c-Reference.html | 312 +
.../cpp/ref/names/com/sun/star/uno/c-Sequence.html | 241 +
.../udk/cpp/ref/names/com/sun/star/uno/c-Type.html | 219 +
.../names/com/sun/star/uno/c-TypeDescription.html | 233 +
.../names/com/sun/star/uno/c-WeakReference.html | 137 +
.../com/sun/star/uno/c-WeakReferenceHelper.html | 165 +
.../sun/star/uno/e-__UnoReference_NoAcquire.html | 76 +
.../com/sun/star/uno/e-__UnoReference_Query.html | 82 +
.../com/sun/star/uno/e-__UnoType_NoAcquire.html | 73 +
.../udk/cpp/ref/names/com/sun/star/uno/index.html | 314 +
.../cpp/ref/names/com/sun/star/uno/o-Any.h.html | 130 +
.../cpp/ref/names/com/sun/star/uno/o-Any.hxx.html | 1041 ++
.../ref/names/com/sun/star/uno/o-Sequence.hxx.html | 84 +
.../com/sun/star/uno/o-current_context.hxx.html | 151 +
.../ref/names/com/sun/star/uno/o-genfunc.hxx.html | 167 +
.../ref/names/com/sun/star/uno/o-mapping.hxx.html | 202 +
.../udk/cpp/ref/names/cppu/AccessControl/d.html | 47 +
.../udk/cpp/ref/names/cppu/AccessControl/o.html | 468 +
.../names/cppu/AggImplInheritanceHelper1/d.html | 39 +
.../names/cppu/AggImplInheritanceHelper1/o.html | 279 +
.../names/cppu/AggImplInheritanceHelper10/d.html | 39 +
.../names/cppu/AggImplInheritanceHelper10/o.html | 279 +
.../names/cppu/AggImplInheritanceHelper11/d.html | 39 +
.../names/cppu/AggImplInheritanceHelper11/o.html | 279 +
.../names/cppu/AggImplInheritanceHelper12/d.html | 39 +
.../names/cppu/AggImplInheritanceHelper12/o.html | 279 +
.../names/cppu/AggImplInheritanceHelper2/d.html | 39 +
.../names/cppu/AggImplInheritanceHelper2/o.html | 279 +
.../names/cppu/AggImplInheritanceHelper3/d.html | 39 +
.../names/cppu/AggImplInheritanceHelper3/o.html | 279 +
.../names/cppu/AggImplInheritanceHelper4/d.html | 39 +
.../names/cppu/AggImplInheritanceHelper4/o.html | 279 +
.../names/cppu/AggImplInheritanceHelper5/d.html | 39 +
.../names/cppu/AggImplInheritanceHelper5/o.html | 279 +
.../names/cppu/AggImplInheritanceHelper6/d.html | 39 +
.../names/cppu/AggImplInheritanceHelper6/o.html | 279 +
.../names/cppu/AggImplInheritanceHelper7/d.html | 39 +
.../names/cppu/AggImplInheritanceHelper7/o.html | 279 +
.../names/cppu/AggImplInheritanceHelper8/d.html | 39 +
.../names/cppu/AggImplInheritanceHelper8/o.html | 279 +
.../names/cppu/AggImplInheritanceHelper9/d.html | 39 +
.../names/cppu/AggImplInheritanceHelper9/o.html | 279 +
.../cpp/ref/names/cppu/ContextEntry_Init/d.html | 87 +
.../cpp/ref/names/cppu/ContextEntry_Init/o.html | 39 +
.../cpp/ref/names/cppu/IPropertyArrayHelper/d.html | 39 +
.../cpp/ref/names/cppu/IPropertyArrayHelper/o.html | 608 +
content/udk/cpp/ref/names/cppu/ImplHelper1/d.html | 39 +
content/udk/cpp/ref/names/cppu/ImplHelper1/o.html | 163 +
content/udk/cpp/ref/names/cppu/ImplHelper10/d.html | 39 +
content/udk/cpp/ref/names/cppu/ImplHelper10/o.html | 163 +
content/udk/cpp/ref/names/cppu/ImplHelper11/d.html | 39 +
content/udk/cpp/ref/names/cppu/ImplHelper11/o.html | 163 +
content/udk/cpp/ref/names/cppu/ImplHelper12/d.html | 39 +
content/udk/cpp/ref/names/cppu/ImplHelper12/o.html | 163 +
content/udk/cpp/ref/names/cppu/ImplHelper2/d.html | 39 +
content/udk/cpp/ref/names/cppu/ImplHelper2/o.html | 163 +
content/udk/cpp/ref/names/cppu/ImplHelper3/d.html | 39 +
content/udk/cpp/ref/names/cppu/ImplHelper3/o.html | 163 +
content/udk/cpp/ref/names/cppu/ImplHelper4/d.html | 39 +
content/udk/cpp/ref/names/cppu/ImplHelper4/o.html | 163 +
content/udk/cpp/ref/names/cppu/ImplHelper5/d.html | 39 +
content/udk/cpp/ref/names/cppu/ImplHelper5/o.html | 163 +
content/udk/cpp/ref/names/cppu/ImplHelper6/d.html | 39 +
content/udk/cpp/ref/names/cppu/ImplHelper6/o.html | 163 +
content/udk/cpp/ref/names/cppu/ImplHelper7/d.html | 39 +
content/udk/cpp/ref/names/cppu/ImplHelper7/o.html | 163 +
content/udk/cpp/ref/names/cppu/ImplHelper8/d.html | 39 +
content/udk/cpp/ref/names/cppu/ImplHelper8/o.html | 163 +
content/udk/cpp/ref/names/cppu/ImplHelper9/d.html | 39 +
content/udk/cpp/ref/names/cppu/ImplHelper9/o.html | 163 +
.../ref/names/cppu/ImplInheritanceHelper1/d.html | 39 +
.../ref/names/cppu/ImplInheritanceHelper1/o.html | 235 +
.../ref/names/cppu/ImplInheritanceHelper10/d.html | 39 +
.../ref/names/cppu/ImplInheritanceHelper10/o.html | 235 +
.../ref/names/cppu/ImplInheritanceHelper11/d.html | 39 +
.../ref/names/cppu/ImplInheritanceHelper11/o.html | 235 +
.../ref/names/cppu/ImplInheritanceHelper12/d.html | 39 +
.../ref/names/cppu/ImplInheritanceHelper12/o.html | 235 +
.../ref/names/cppu/ImplInheritanceHelper2/d.html | 39 +
.../ref/names/cppu/ImplInheritanceHelper2/o.html | 235 +
.../ref/names/cppu/ImplInheritanceHelper3/d.html | 39 +
.../ref/names/cppu/ImplInheritanceHelper3/o.html | 235 +
.../ref/names/cppu/ImplInheritanceHelper4/d.html | 39 +
.../ref/names/cppu/ImplInheritanceHelper4/o.html | 235 +
.../ref/names/cppu/ImplInheritanceHelper5/d.html | 39 +
.../ref/names/cppu/ImplInheritanceHelper5/o.html | 235 +
.../ref/names/cppu/ImplInheritanceHelper6/d.html | 39 +
.../ref/names/cppu/ImplInheritanceHelper6/o.html | 235 +
.../ref/names/cppu/ImplInheritanceHelper7/d.html | 39 +
.../ref/names/cppu/ImplInheritanceHelper7/o.html | 235 +
.../ref/names/cppu/ImplInheritanceHelper8/d.html | 39 +
.../ref/names/cppu/ImplInheritanceHelper8/o.html | 235 +
.../ref/names/cppu/ImplInheritanceHelper9/d.html | 39 +
.../ref/names/cppu/ImplInheritanceHelper9/o.html | 235 +
.../cpp/ref/names/cppu/ImplementationEntry/d.html | 83 +
.../cpp/ref/names/cppu/ImplementationEntry/o.html | 39 +
.../cpp/ref/names/cppu/OBroadcastHelperVar/d.html | 91 +
.../cpp/ref/names/cppu/OBroadcastHelperVar/o.html | 249 +
.../udk/cpp/ref/names/cppu/OComponentHelper/d.html | 39 +
.../udk/cpp/ref/names/cppu/OComponentHelper/o.html | 567 +
.../cpp/ref/names/cppu/OImplementationId/d.html | 39 +
.../cpp/ref/names/cppu/OImplementationId/o.html | 240 +
.../names/cppu/OInterfaceContainerHelper/d.html | 88 +
.../names/cppu/OInterfaceContainerHelper/o.html | 726 ++
.../ref/names/cppu/OInterfaceIteratorHelper/d.html | 71 +
.../ref/names/cppu/OInterfaceIteratorHelper/o.html | 359 +
.../cppu/OMultiTypeInterfaceContainerHelper/d.html | 55 +
.../cppu/OMultiTypeInterfaceContainerHelper/o.html | 715 ++
.../t-keyType.html | 48 +
.../OMultiTypeInterfaceContainerHelperInt32/d.html | 55 +
.../OMultiTypeInterfaceContainerHelperInt32/o.html | 715 ++
.../t-keyType.html | 48 +
.../OMultiTypeInterfaceContainerHelperVar/d.html | 55 +
.../OMultiTypeInterfaceContainerHelperVar/o.html | 725 ++
.../t-keyType.html | 48 +
.../cpp/ref/names/cppu/OPropertyArrayHelper/d.html | 81 +
.../cpp/ref/names/cppu/OPropertyArrayHelper/o.html | 620 +
.../cpp/ref/names/cppu/OPropertySetHelper/d.html | 94 +
.../cpp/ref/names/cppu/OPropertySetHelper/o.html | 1466 +++
.../udk/cpp/ref/names/cppu/OTypeCollection/d.html | 47 +
.../udk/cpp/ref/names/cppu/OTypeCollection/o.html | 930 ++
.../udk/cpp/ref/names/cppu/OWeakAggObject/d.html | 53 +
.../udk/cpp/ref/names/cppu/OWeakAggObject/o.html | 402 +
content/udk/cpp/ref/names/cppu/OWeakObject/d.html | 58 +
content/udk/cpp/ref/names/cppu/OWeakObject/o.html | 485 +
.../names/cppu/WeakAggComponentImplHelper1/d.html | 39 +
.../names/cppu/WeakAggComponentImplHelper1/o.html | 320 +
.../names/cppu/WeakAggComponentImplHelper10/d.html | 39 +
.../names/cppu/WeakAggComponentImplHelper10/o.html | 320 +
.../names/cppu/WeakAggComponentImplHelper11/d.html | 39 +
.../names/cppu/WeakAggComponentImplHelper11/o.html | 320 +
.../names/cppu/WeakAggComponentImplHelper12/d.html | 39 +
.../names/cppu/WeakAggComponentImplHelper12/o.html | 320 +
.../names/cppu/WeakAggComponentImplHelper2/d.html | 39 +
.../names/cppu/WeakAggComponentImplHelper2/o.html | 320 +
.../names/cppu/WeakAggComponentImplHelper3/d.html | 39 +
.../names/cppu/WeakAggComponentImplHelper3/o.html | 320 +
.../names/cppu/WeakAggComponentImplHelper4/d.html | 39 +
.../names/cppu/WeakAggComponentImplHelper4/o.html | 320 +
.../names/cppu/WeakAggComponentImplHelper5/d.html | 39 +
.../names/cppu/WeakAggComponentImplHelper5/o.html | 320 +
.../names/cppu/WeakAggComponentImplHelper6/d.html | 39 +
.../names/cppu/WeakAggComponentImplHelper6/o.html | 320 +
.../names/cppu/WeakAggComponentImplHelper7/d.html | 39 +
.../names/cppu/WeakAggComponentImplHelper7/o.html | 320 +
.../names/cppu/WeakAggComponentImplHelper8/d.html | 39 +
.../names/cppu/WeakAggComponentImplHelper8/o.html | 320 +
.../names/cppu/WeakAggComponentImplHelper9/d.html | 39 +
.../names/cppu/WeakAggComponentImplHelper9/o.html | 320 +
.../cpp/ref/names/cppu/WeakAggImplHelper1/d.html | 39 +
.../cpp/ref/names/cppu/WeakAggImplHelper1/o.html | 279 +
.../cpp/ref/names/cppu/WeakAggImplHelper10/d.html | 39 +
.../cpp/ref/names/cppu/WeakAggImplHelper10/o.html | 279 +
.../cpp/ref/names/cppu/WeakAggImplHelper11/d.html | 39 +
.../cpp/ref/names/cppu/WeakAggImplHelper11/o.html | 279 +
.../cpp/ref/names/cppu/WeakAggImplHelper12/d.html | 39 +
.../cpp/ref/names/cppu/WeakAggImplHelper12/o.html | 279 +
.../cpp/ref/names/cppu/WeakAggImplHelper2/d.html | 39 +
.../cpp/ref/names/cppu/WeakAggImplHelper2/o.html | 279 +
.../cpp/ref/names/cppu/WeakAggImplHelper3/d.html | 39 +
.../cpp/ref/names/cppu/WeakAggImplHelper3/o.html | 279 +
.../cpp/ref/names/cppu/WeakAggImplHelper4/d.html | 39 +
.../cpp/ref/names/cppu/WeakAggImplHelper4/o.html | 279 +
.../cpp/ref/names/cppu/WeakAggImplHelper5/d.html | 39 +
.../cpp/ref/names/cppu/WeakAggImplHelper5/o.html | 279 +
.../cpp/ref/names/cppu/WeakAggImplHelper6/d.html | 39 +
.../cpp/ref/names/cppu/WeakAggImplHelper6/o.html | 279 +
.../cpp/ref/names/cppu/WeakAggImplHelper7/d.html | 39 +
.../cpp/ref/names/cppu/WeakAggImplHelper7/o.html | 279 +
.../cpp/ref/names/cppu/WeakAggImplHelper8/d.html | 39 +
.../cpp/ref/names/cppu/WeakAggImplHelper8/o.html | 279 +
.../cpp/ref/names/cppu/WeakAggImplHelper9/d.html | 39 +
.../cpp/ref/names/cppu/WeakAggImplHelper9/o.html | 279 +
.../ref/names/cppu/WeakComponentImplHelper1/d.html | 39 +
.../ref/names/cppu/WeakComponentImplHelper1/o.html | 276 +
.../names/cppu/WeakComponentImplHelper10/d.html | 39 +
.../names/cppu/WeakComponentImplHelper10/o.html | 276 +
.../names/cppu/WeakComponentImplHelper11/d.html | 39 +
.../names/cppu/WeakComponentImplHelper11/o.html | 276 +
.../names/cppu/WeakComponentImplHelper12/d.html | 39 +
.../names/cppu/WeakComponentImplHelper12/o.html | 276 +
.../ref/names/cppu/WeakComponentImplHelper2/d.html | 39 +
.../ref/names/cppu/WeakComponentImplHelper2/o.html | 276 +
.../ref/names/cppu/WeakComponentImplHelper3/d.html | 39 +
.../ref/names/cppu/WeakComponentImplHelper3/o.html | 276 +
.../ref/names/cppu/WeakComponentImplHelper4/d.html | 39 +
.../ref/names/cppu/WeakComponentImplHelper4/o.html | 276 +
.../ref/names/cppu/WeakComponentImplHelper5/d.html | 39 +
.../ref/names/cppu/WeakComponentImplHelper5/o.html | 276 +
.../ref/names/cppu/WeakComponentImplHelper6/d.html | 39 +
.../ref/names/cppu/WeakComponentImplHelper6/o.html | 276 +
.../ref/names/cppu/WeakComponentImplHelper7/d.html | 39 +
.../ref/names/cppu/WeakComponentImplHelper7/o.html | 276 +
.../ref/names/cppu/WeakComponentImplHelper8/d.html | 39 +
.../ref/names/cppu/WeakComponentImplHelper8/o.html | 276 +
.../ref/names/cppu/WeakComponentImplHelper9/d.html | 39 +
.../ref/names/cppu/WeakComponentImplHelper9/o.html | 276 +
.../udk/cpp/ref/names/cppu/WeakImplHelper1/d.html | 39 +
.../udk/cpp/ref/names/cppu/WeakImplHelper1/o.html | 235 +
.../udk/cpp/ref/names/cppu/WeakImplHelper10/d.html | 39 +
.../udk/cpp/ref/names/cppu/WeakImplHelper10/o.html | 235 +
.../udk/cpp/ref/names/cppu/WeakImplHelper11/d.html | 39 +
.../udk/cpp/ref/names/cppu/WeakImplHelper11/o.html | 235 +
.../udk/cpp/ref/names/cppu/WeakImplHelper12/d.html | 39 +
.../udk/cpp/ref/names/cppu/WeakImplHelper12/o.html | 235 +
.../udk/cpp/ref/names/cppu/WeakImplHelper2/d.html | 39 +
.../udk/cpp/ref/names/cppu/WeakImplHelper2/o.html | 235 +
.../udk/cpp/ref/names/cppu/WeakImplHelper3/d.html | 39 +
.../udk/cpp/ref/names/cppu/WeakImplHelper3/o.html | 235 +
.../udk/cpp/ref/names/cppu/WeakImplHelper4/d.html | 39 +
.../udk/cpp/ref/names/cppu/WeakImplHelper4/o.html | 235 +
.../udk/cpp/ref/names/cppu/WeakImplHelper5/d.html | 39 +
.../udk/cpp/ref/names/cppu/WeakImplHelper5/o.html | 235 +
.../udk/cpp/ref/names/cppu/WeakImplHelper6/d.html | 39 +
.../udk/cpp/ref/names/cppu/WeakImplHelper6/o.html | 235 +
.../udk/cpp/ref/names/cppu/WeakImplHelper7/d.html | 39 +
.../udk/cpp/ref/names/cppu/WeakImplHelper7/o.html | 235 +
.../udk/cpp/ref/names/cppu/WeakImplHelper8/d.html | 39 +
.../udk/cpp/ref/names/cppu/WeakImplHelper8/o.html | 235 +
.../udk/cpp/ref/names/cppu/WeakImplHelper9/d.html | 39 +
.../udk/cpp/ref/names/cppu/WeakImplHelper9/o.html | 235 +
.../udk/cpp/ref/names/cppu/c-AccessControl.html | 176 +
.../names/cppu/c-AggImplInheritanceHelper1.html | 155 +
.../names/cppu/c-AggImplInheritanceHelper10.html | 173 +
.../names/cppu/c-AggImplInheritanceHelper11.html | 175 +
.../names/cppu/c-AggImplInheritanceHelper12.html | 177 +
.../names/cppu/c-AggImplInheritanceHelper2.html | 157 +
.../names/cppu/c-AggImplInheritanceHelper3.html | 159 +
.../names/cppu/c-AggImplInheritanceHelper4.html | 161 +
.../names/cppu/c-AggImplInheritanceHelper5.html | 163 +
.../names/cppu/c-AggImplInheritanceHelper6.html | 165 +
.../names/cppu/c-AggImplInheritanceHelper7.html | 167 +
.../names/cppu/c-AggImplInheritanceHelper8.html | 169 +
.../names/cppu/c-AggImplInheritanceHelper9.html | 171 +
.../cpp/ref/names/cppu/c-ContextEntry_Init.html | 116 +
.../cpp/ref/names/cppu/c-IPropertyArrayHelper.html | 172 +
content/udk/cpp/ref/names/cppu/c-ImplHelper1.html | 131 +
content/udk/cpp/ref/names/cppu/c-ImplHelper10.html | 149 +
content/udk/cpp/ref/names/cppu/c-ImplHelper11.html | 151 +
content/udk/cpp/ref/names/cppu/c-ImplHelper12.html | 153 +
content/udk/cpp/ref/names/cppu/c-ImplHelper2.html | 133 +
content/udk/cpp/ref/names/cppu/c-ImplHelper3.html | 135 +
content/udk/cpp/ref/names/cppu/c-ImplHelper4.html | 137 +
content/udk/cpp/ref/names/cppu/c-ImplHelper5.html | 139 +
content/udk/cpp/ref/names/cppu/c-ImplHelper6.html | 141 +
content/udk/cpp/ref/names/cppu/c-ImplHelper7.html | 143 +
content/udk/cpp/ref/names/cppu/c-ImplHelper8.html | 145 +
content/udk/cpp/ref/names/cppu/c-ImplHelper9.html | 147 +
.../ref/names/cppu/c-ImplInheritanceHelper1.html | 150 +
.../ref/names/cppu/c-ImplInheritanceHelper10.html | 168 +
.../ref/names/cppu/c-ImplInheritanceHelper11.html | 170 +
.../ref/names/cppu/c-ImplInheritanceHelper12.html | 172 +
.../ref/names/cppu/c-ImplInheritanceHelper2.html | 152 +
.../ref/names/cppu/c-ImplInheritanceHelper3.html | 154 +
.../ref/names/cppu/c-ImplInheritanceHelper4.html | 156 +
.../ref/names/cppu/c-ImplInheritanceHelper5.html | 158 +
.../ref/names/cppu/c-ImplInheritanceHelper6.html | 160 +
.../ref/names/cppu/c-ImplInheritanceHelper7.html | 162 +
.../ref/names/cppu/c-ImplInheritanceHelper8.html | 164 +
.../ref/names/cppu/c-ImplInheritanceHelper9.html | 166 +
.../cpp/ref/names/cppu/c-ImplementationEntry.html | 118 +
.../cpp/ref/names/cppu/c-OBroadcastHelperVar.html | 156 +
.../udk/cpp/ref/names/cppu/c-OComponentHelper.html | 215 +
.../cpp/ref/names/cppu/c-OImplementationId.html | 127 +
.../names/cppu/c-OInterfaceContainerHelper.html | 253 +
.../ref/names/cppu/c-OInterfaceIteratorHelper.html | 189 +
.../cppu/c-OMultiTypeInterfaceContainerHelper.html | 242 +
.../c-OMultiTypeInterfaceContainerHelperInt32.html | 242 +
.../c-OMultiTypeInterfaceContainerHelperVar.html | 249 +
.../cpp/ref/names/cppu/c-OPropertyArrayHelper.html | 243 +
.../cpp/ref/names/cppu/c-OPropertySetHelper.html | 349 +
.../udk/cpp/ref/names/cppu/c-OTypeCollection.html | 203 +
.../udk/cpp/ref/names/cppu/c-OWeakAggObject.html | 219 +
content/udk/cpp/ref/names/cppu/c-OWeakObject.html | 228 +
.../names/cppu/c-WeakAggComponentImplHelper1.html | 170 +
.../names/cppu/c-WeakAggComponentImplHelper10.html | 188 +
.../names/cppu/c-WeakAggComponentImplHelper11.html | 190 +
.../names/cppu/c-WeakAggComponentImplHelper12.html | 192 +
.../names/cppu/c-WeakAggComponentImplHelper2.html | 172 +
.../names/cppu/c-WeakAggComponentImplHelper3.html | 174 +
.../names/cppu/c-WeakAggComponentImplHelper4.html | 176 +
.../names/cppu/c-WeakAggComponentImplHelper5.html | 178 +
.../names/cppu/c-WeakAggComponentImplHelper6.html | 180 +
.../names/cppu/c-WeakAggComponentImplHelper7.html | 182 +
.../names/cppu/c-WeakAggComponentImplHelper8.html | 184 +
.../names/cppu/c-WeakAggComponentImplHelper9.html | 186 +
.../cpp/ref/names/cppu/c-WeakAggImplHelper1.html | 159 +
.../cpp/ref/names/cppu/c-WeakAggImplHelper10.html | 177 +
.../cpp/ref/names/cppu/c-WeakAggImplHelper11.html | 179 +
.../cpp/ref/names/cppu/c-WeakAggImplHelper12.html | 181 +
.../cpp/ref/names/cppu/c-WeakAggImplHelper2.html | 161 +
.../cpp/ref/names/cppu/c-WeakAggImplHelper3.html | 163 +
.../cpp/ref/names/cppu/c-WeakAggImplHelper4.html | 165 +
.../cpp/ref/names/cppu/c-WeakAggImplHelper5.html | 167 +
.../cpp/ref/names/cppu/c-WeakAggImplHelper6.html | 169 +
.../cpp/ref/names/cppu/c-WeakAggImplHelper7.html | 171 +
.../cpp/ref/names/cppu/c-WeakAggImplHelper8.html | 173 +
.../cpp/ref/names/cppu/c-WeakAggImplHelper9.html | 175 +
.../ref/names/cppu/c-WeakComponentImplHelper1.html | 160 +
.../names/cppu/c-WeakComponentImplHelper10.html | 178 +
.../names/cppu/c-WeakComponentImplHelper11.html | 180 +
.../names/cppu/c-WeakComponentImplHelper12.html | 182 +
.../ref/names/cppu/c-WeakComponentImplHelper2.html | 162 +
.../ref/names/cppu/c-WeakComponentImplHelper3.html | 164 +
.../ref/names/cppu/c-WeakComponentImplHelper4.html | 166 +
.../ref/names/cppu/c-WeakComponentImplHelper5.html | 168 +
.../ref/names/cppu/c-WeakComponentImplHelper6.html | 170 +
.../ref/names/cppu/c-WeakComponentImplHelper7.html | 172 +
.../ref/names/cppu/c-WeakComponentImplHelper8.html | 174 +
.../ref/names/cppu/c-WeakComponentImplHelper9.html | 176 +
.../udk/cpp/ref/names/cppu/c-WeakImplHelper1.html | 145 +
.../udk/cpp/ref/names/cppu/c-WeakImplHelper10.html | 163 +
.../udk/cpp/ref/names/cppu/c-WeakImplHelper11.html | 165 +
.../udk/cpp/ref/names/cppu/c-WeakImplHelper12.html | 167 +
.../udk/cpp/ref/names/cppu/c-WeakImplHelper2.html | 147 +
.../udk/cpp/ref/names/cppu/c-WeakImplHelper3.html | 149 +
.../udk/cpp/ref/names/cppu/c-WeakImplHelper4.html | 151 +
.../udk/cpp/ref/names/cppu/c-WeakImplHelper5.html | 153 +
.../udk/cpp/ref/names/cppu/c-WeakImplHelper6.html | 155 +
.../udk/cpp/ref/names/cppu/c-WeakImplHelper7.html | 157 +
.../udk/cpp/ref/names/cppu/c-WeakImplHelper8.html | 159 +
.../udk/cpp/ref/names/cppu/c-WeakImplHelper9.html | 161 +
.../udk/cpp/ref/names/cppu/c-equalInt32_Impl.html | 100 +
.../udk/cpp/ref/names/cppu/c-hashInt32_Impl.html | 100 +
.../udk/cpp/ref/names/cppu/c-hashType_Impl.html | 100 +
.../udk/cpp/ref/names/cppu/equalInt32_Impl/d.html | 39 +
.../udk/cpp/ref/names/cppu/equalInt32_Impl/o.html | 84 +
.../udk/cpp/ref/names/cppu/hashInt32_Impl/d.html | 39 +
.../udk/cpp/ref/names/cppu/hashInt32_Impl/o.html | 80 +
.../udk/cpp/ref/names/cppu/hashType_Impl/d.html | 39 +
.../udk/cpp/ref/names/cppu/hashType_Impl/o.html | 80 +
content/udk/cpp/ref/names/cppu/index.html | 810 ++
.../udk/cpp/ref/names/cppu/o-bootstrap.hxx.html | 424 +
.../ref/names/cppu/o-component_context.hxx.html | 118 +
content/udk/cpp/ref/names/cppu/o-exc_hlp.hxx.html | 101 +
content/udk/cpp/ref/names/cppu/o-factory.hxx.html | 575 +
.../udk/cpp/ref/names/cppu/o-proptypehlp.hxx.html | 680 ++
.../cpp/ref/names/cppu/o-queryinterface.hxx.html | 1936 +++
.../cpp/ref/names/cppu/o-servicefactory.hxx.html | 300 +
content/udk/cpp/ref/names/cppu/o-shlib.hxx.html | 236 +
.../udk/cpp/ref/names/cppu/o-stdidlclass.hxx.html | 851 ++
.../udk/cpp/ref/names/cppu/t-OBroadcastHelper.html | 47 +
content/udk/cpp/ref/names/d-Sequence.hxx.html | 48 +
content/udk/cpp/ref/names/d-context.h.html | 91 +
content/udk/cpp/ref/names/e-RTMethodMode.html | 110 +
content/udk/cpp/ref/names/e-RTParamMode.html | 104 +
content/udk/cpp/ref/names/e-RTReferenceType.html | 116 +
content/udk/cpp/ref/names/e-RTTypeClass.html | 196 +
content/udk/cpp/ref/names/e-RTTypeSource.html | 78 +
content/udk/cpp/ref/names/e-RTValueType.html | 114 +
content/udk/cpp/ref/names/e-RegError.html | 303 +
content/udk/cpp/ref/names/e-RegKeyType.html | 86 +
content/udk/cpp/ref/names/e-RegValueType.html | 142 +
.../udk/cpp/ref/names/e-__rtl_CipherAlgorithm.html | 51 +
.../udk/cpp/ref/names/e-__rtl_CipherDirection.html | 51 +
content/udk/cpp/ref/names/e-__rtl_CipherError.html | 51 +
content/udk/cpp/ref/names/e-__rtl_CipherMode.html | 51 +
.../udk/cpp/ref/names/e-__rtl_DigestAlgorithm.html | 51 +
content/udk/cpp/ref/names/e-__rtl_DigestError.html | 51 +
content/udk/cpp/ref/names/e-__rtl_RandomError.html | 51 +
content/udk/cpp/ref/names/e-__sal_NoAcquire.html | 67 +
.../udk/cpp/ref/names/e-__store_AccessMode.html | 51 +
content/udk/cpp/ref/names/e-__store_Error.html | 51 +
.../udk/cpp/ref/names/e-_typelib_TypeClass.html | 323 +
content/udk/cpp/ref/names/e-e_Anonymous__1.html | 73 +
content/udk/cpp/ref/names/e-e_Anonymous__10.html | 73 +
content/udk/cpp/ref/names/e-e_Anonymous__11.html | 77 +
content/udk/cpp/ref/names/e-e_Anonymous__12.html | 93 +
content/udk/cpp/ref/names/e-e_Anonymous__13.html | 93 +
content/udk/cpp/ref/names/e-e_Anonymous__14.html | 77 +
content/udk/cpp/ref/names/e-e_Anonymous__16.html | 293 +
content/udk/cpp/ref/names/e-e_Anonymous__17.html | 89 +
content/udk/cpp/ref/names/e-e_Anonymous__18.html | 85 +
content/udk/cpp/ref/names/e-e_Anonymous__19.html | 77 +
content/udk/cpp/ref/names/e-e_Anonymous__2.html | 81 +
content/udk/cpp/ref/names/e-e_Anonymous__21.html | 105 +
content/udk/cpp/ref/names/e-e_Anonymous__23.html | 155 +
content/udk/cpp/ref/names/e-e_Anonymous__24.html | 105 +
content/udk/cpp/ref/names/e-e_Anonymous__25.html | 100 +
content/udk/cpp/ref/names/e-e_Anonymous__3.html | 85 +
content/udk/cpp/ref/names/e-e_Anonymous__4.html | 137 +
content/udk/cpp/ref/names/e-e_Anonymous__5.html | 73 +
content/udk/cpp/ref/names/e-e_Anonymous__6.html | 85 +
content/udk/cpp/ref/names/e-e_Anonymous__7.html | 77 +
content/udk/cpp/ref/names/e-e_Anonymous__8.html | 185 +
content/udk/cpp/ref/names/e-e_Anonymous__9.html | 81 +
content/udk/cpp/ref/names/index.html | 5150 ++++++++
content/udk/cpp/ref/names/o-Any.h.html | 100 +
content/udk/cpp/ref/names/o-Sequence.hxx.html | 164 +
content/udk/cpp/ref/names/o-Type.hxx.html | 1012 ++
content/udk/cpp/ref/names/o-alloc.h.html | 380 +
content/udk/cpp/ref/names/o-any2.h.html | 712 ++
content/udk/cpp/ref/names/o-bootstrap.h.html | 454 +
content/udk/cpp/ref/names/o-byteseq.h.html | 734 ++
content/udk/cpp/ref/names/o-cipher.h.html | 797 ++
content/udk/cpp/ref/names/o-conditn.h.html | 400 +
content/udk/cpp/ref/names/o-crc.h.html | 122 +
content/udk/cpp/ref/names/o-current_context.h.html | 203 +
content/udk/cpp/ref/names/o-data.h.html | 1130 ++
content/udk/cpp/ref/names/o-diagnose.h.html | 266 +
content/udk/cpp/ref/names/o-digest.h.html | 2803 +++++
content/udk/cpp/ref/names/o-environment.h.html | 431 +
content/udk/cpp/ref/names/o-file.h.html | 2925 +++++
content/udk/cpp/ref/names/o-interlck.h.html | 160 +
content/udk/cpp/ref/names/o-locale.h.html | 498 +
content/udk/cpp/ref/names/o-logfile.h.html | 118 +
content/udk/cpp/ref/names/o-main.h.html | 77 +
content/udk/cpp/ref/names/o-mapping.h.html | 485 +
content/udk/cpp/ref/names/o-memory.h.html | 336 +
content/udk/cpp/ref/names/o-module.h.html | 274 +
content/udk/cpp/ref/names/o-mutex.h.html | 374 +
content/udk/cpp/ref/names/o-nlsupport.h.html | 103 +
content/udk/cpp/ref/names/o-pipe.h.html | 537 +
content/udk/cpp/ref/names/o-process.h.html | 246 +
content/udk/cpp/ref/names/o-profile.h.html | 750 ++
content/udk/cpp/ref/names/o-random.h.html | 307 +
content/udk/cpp/ref/names/o-registry.h.html | 2649 ++++
content/udk/cpp/ref/names/o-security.h.html | 792 ++
content/udk/cpp/ref/names/o-semaphor.h.html | 307 +
content/udk/cpp/ref/names/o-sequence2.h.html | 772 ++
content/udk/cpp/ref/names/o-signal.h.html | 180 +
content/udk/cpp/ref/names/o-socket.h.html | 4044 +++++++
content/udk/cpp/ref/names/o-store.h.html | 1993 +++
content/udk/cpp/ref/names/o-strbuf.h.html | 395 +
content/udk/cpp/ref/names/o-string.h.html | 4589 +++++++
content/udk/cpp/ref/names/o-tencinfo.h.html | 496 +
content/udk/cpp/ref/names/o-textcvt.h.html | 696 ++
content/udk/cpp/ref/names/o-thread.h.html | 1049 ++
content/udk/cpp/ref/names/o-threadpool.h.html | 572 +
content/udk/cpp/ref/names/o-time.h.html | 417 +
content/udk/cpp/ref/names/o-tres.h.html | 128 +
content/udk/cpp/ref/names/o-typedescription.h.html | 2668 ++++
content/udk/cpp/ref/names/o-unload.h.html | 579 +
content/udk/cpp/ref/names/o-uri.h.html | 313 +
content/udk/cpp/ref/names/o-ustrbuf.h.html | 504 +
content/udk/cpp/ref/names/o-ustring.h.html | 5365 ++++++++
content/udk/cpp/ref/names/o-util.h.html | 102 +
content/udk/cpp/ref/names/o-uuid.h.html | 305 +
.../udk/cpp/ref/names/osl/AcceptorSocket/d.html | 39 +
.../udk/cpp/ref/names/osl/AcceptorSocket/o.html | 282 +
.../udk/cpp/ref/names/osl/ClearableGuard/d.html | 47 +
.../udk/cpp/ref/names/osl/ClearableGuard/o.html | 203 +
content/udk/cpp/ref/names/osl/Condition/d.html | 47 +
.../udk/cpp/ref/names/osl/Condition/e-Result.html | 70 +
content/udk/cpp/ref/names/osl/Condition/o.html | 313 +
.../udk/cpp/ref/names/osl/ConnectorSocket/d.html | 39 +
.../udk/cpp/ref/names/osl/ConnectorSocket/o.html | 176 +
.../udk/cpp/ref/names/osl/DatagramSocket/d.html | 39 +
.../udk/cpp/ref/names/osl/DatagramSocket/o.html | 301 +
content/udk/cpp/ref/names/osl/File/d.html | 55 +
content/udk/cpp/ref/names/osl/File/o.html | 1259 ++
content/udk/cpp/ref/names/osl/FileBase/d.html | 39 +
content/udk/cpp/ref/names/osl/FileBase/e-RC.html | 242 +
content/udk/cpp/ref/names/osl/FileBase/o.html | 459 +
content/udk/cpp/ref/names/osl/FileStatus/d.html | 55 +
.../udk/cpp/ref/names/osl/FileStatus/e-Type.html | 90 +
content/udk/cpp/ref/names/osl/FileStatus/o.html | 672 ++
content/udk/cpp/ref/names/osl/Guard/d.html | 47 +
content/udk/cpp/ref/names/osl/Guard/o.html | 162 +
content/udk/cpp/ref/names/osl/Module/d.html | 47 +
content/udk/cpp/ref/names/osl/Module/o.html | 477 +
content/udk/cpp/ref/names/osl/Mutex/d.html | 47 +
content/udk/cpp/ref/names/osl/Mutex/o.html | 461 +
content/udk/cpp/ref/names/osl/Pipe/d.html | 47 +
content/udk/cpp/ref/names/osl/Pipe/o.html | 989 ++
content/udk/cpp/ref/names/osl/Profile/d.html | 47 +
content/udk/cpp/ref/names/osl/Profile/o.html | 666 +
.../udk/cpp/ref/names/osl/ResettableGuard/d.html | 47 +
.../udk/cpp/ref/names/osl/ResettableGuard/o.html | 157 +
content/udk/cpp/ref/names/osl/Security/d.html | 47 +
content/udk/cpp/ref/names/osl/Security/o.html | 611 +
content/udk/cpp/ref/names/osl/Semaphore/d.html | 47 +
content/udk/cpp/ref/names/osl/Semaphore/o.html | 281 +
content/udk/cpp/ref/names/osl/Socket/d.html | 47 +
content/udk/cpp/ref/names/osl/Socket/o.html | 1862 +++
content/udk/cpp/ref/names/osl/SocketAddr/d.html | 47 +
content/udk/cpp/ref/names/osl/SocketAddr/o.html | 1110 ++
content/udk/cpp/ref/names/osl/StreamPipe/d.html | 39 +
content/udk/cpp/ref/names/osl/StreamPipe/o.html | 764 ++
content/udk/cpp/ref/names/osl/StreamSocket/d.html | 39 +
content/udk/cpp/ref/names/osl/StreamSocket/o.html | 544 +
content/udk/cpp/ref/names/osl/Thread/d.html | 47 +
content/udk/cpp/ref/names/osl/Thread/o.html | 994 ++
content/udk/cpp/ref/names/osl/ThreadData/d.html | 47 +
content/udk/cpp/ref/names/osl/ThreadData/o.html | 336 +
content/udk/cpp/ref/names/osl/VolumeDevice/d.html | 47 +
content/udk/cpp/ref/names/osl/VolumeDevice/o.html | 301 +
content/udk/cpp/ref/names/osl/VolumeInfo/d.html | 63 +
content/udk/cpp/ref/names/osl/VolumeInfo/o.html | 845 ++
.../udk/cpp/ref/names/osl/c-AcceptorSocket.html | 125 +
.../udk/cpp/ref/names/osl/c-ClearableGuard.html | 148 +
content/udk/cpp/ref/names/osl/c-Condition.html | 181 +
.../udk/cpp/ref/names/osl/c-ConnectorSocket.html | 113 +
.../udk/cpp/ref/names/osl/c-DatagramSocket.html | 122 +
content/udk/cpp/ref/names/osl/c-File.html | 270 +
content/udk/cpp/ref/names/osl/c-FileBase.html | 152 +
content/udk/cpp/ref/names/osl/c-FileStatus.html | 232 +
content/udk/cpp/ref/names/osl/c-Guard.html | 142 +
content/udk/cpp/ref/names/osl/c-Module.html | 196 +
content/udk/cpp/ref/names/osl/c-Mutex.html | 196 +
content/udk/cpp/ref/names/osl/c-Pipe.html | 247 +
content/udk/cpp/ref/names/osl/c-Profile.html | 190 +
.../udk/cpp/ref/names/osl/c-ResettableGuard.html | 146 +
content/udk/cpp/ref/names/osl/c-Security.html | 193 +
content/udk/cpp/ref/names/osl/c-Semaphore.html | 155 +
content/udk/cpp/ref/names/osl/c-Socket.html | 329 +
content/udk/cpp/ref/names/osl/c-SocketAddr.html | 264 +
content/udk/cpp/ref/names/osl/c-StreamPipe.html | 178 +
content/udk/cpp/ref/names/osl/c-StreamSocket.html | 149 +
content/udk/cpp/ref/names/osl/c-Thread.html | 295 +
content/udk/cpp/ref/names/osl/c-ThreadData.html | 170 +
content/udk/cpp/ref/names/osl/c-VolumeDevice.html | 173 +
content/udk/cpp/ref/names/osl/c-VolumeInfo.html | 244 +
content/udk/cpp/ref/names/osl/d-profile.hxx.html | 72 +
.../cpp/ref/names/osl/e-__osl_socket_NoCopy.html | 70 +
content/udk/cpp/ref/names/osl/index.html | 221 +
content/udk/cpp/ref/names/osl/o-thread.hxx.html | 91 +
.../cpp/ref/names/osl/t-ClearableMutexGuard.html | 47 +
content/udk/cpp/ref/names/osl/t-MutexGuard.html | 47 +
content/udk/cpp/ref/names/osl/t-ProfileOption.html | 47 +
.../cpp/ref/names/osl/t-ResettableMutexGuard.html | 47 +
content/udk/cpp/ref/names/remote_Connection/d.html | 39 +
content/udk/cpp/ref/names/remote_Connection/o.html | 39 +
content/udk/cpp/ref/names/remote_Context/d.html | 175 +
content/udk/cpp/ref/names/remote_Context/o.html | 39 +
.../cpp/ref/names/remote_DisposingListener/d.html | 39 +
.../cpp/ref/names/remote_DisposingListener/o.html | 39 +
.../cpp/ref/names/remote_InstanceProvider/d.html | 39 +
.../cpp/ref/names/remote_InstanceProvider/o.html | 39 +
content/udk/cpp/ref/names/remote_Interface/d.html | 47 +
content/udk/cpp/ref/names/remote_Interface/o.html | 39 +
content/udk/cpp/ref/names/remote_Mapping/d.html | 63 +
content/udk/cpp/ref/names/remote_Mapping/o.html | 39 +
content/udk/cpp/ref/names/rtl/Bootstrap/d.html | 47 +
content/udk/cpp/ref/names/rtl/Bootstrap/o.html | 541 +
content/udk/cpp/ref/names/rtl/ByteSequence/d.html | 39 +
.../ByteSequence/e-__ByteSequence_NoAcquire.html | 52 +
.../ByteSequence/e-__ByteSequence_NoDefault.html | 52 +
content/udk/cpp/ref/names/rtl/ByteSequence/o.html | 1100 ++
content/udk/cpp/ref/names/rtl/IReference/d.html | 39 +
content/udk/cpp/ref/names/rtl/IReference/o.html | 123 +
content/udk/cpp/ref/names/rtl/Logfile/d.html | 47 +
content/udk/cpp/ref/names/rtl/Logfile/o.html | 229 +
content/udk/cpp/ref/names/rtl/OLocale/d.html | 54 +
content/udk/cpp/ref/names/rtl/OLocale/o.html | 677 ++
content/udk/cpp/ref/names/rtl/OString/d.html | 39 +
content/udk/cpp/ref/names/rtl/OString/o.html | 3105 +++++
content/udk/cpp/ref/names/rtl/OStringBuffer/d.html | 67 +
content/udk/cpp/ref/names/rtl/OStringBuffer/o.html | 2221 ++++
content/udk/cpp/ref/names/rtl/OStringHash/d.html | 39 +
content/udk/cpp/ref/names/rtl/OStringHash/o.html | 102 +
content/udk/cpp/ref/names/rtl/OUString/d.html | 39 +
content/udk/cpp/ref/names/rtl/OUString/o.html | 3907 ++++++
.../udk/cpp/ref/names/rtl/OUStringBuffer/d.html | 67 +
.../udk/cpp/ref/names/rtl/OUStringBuffer/o.html | 2374 ++++
content/udk/cpp/ref/names/rtl/OUStringHash/d.html | 39 +
content/udk/cpp/ref/names/rtl/OUStringHash/o.html | 102 +
content/udk/cpp/ref/names/rtl/Reference/d.html | 53 +
content/udk/cpp/ref/names/rtl/Reference/o.html | 813 ++
content/udk/cpp/ref/names/rtl/TestResult/d.html | 47 +
content/udk/cpp/ref/names/rtl/TestResult/o.html | 327 +
content/udk/cpp/ref/names/rtl/Uri/d.html | 39 +
content/udk/cpp/ref/names/rtl/Uri/o.html | 214 +
content/udk/cpp/ref/names/rtl/c-Bootstrap.html | 188 +
content/udk/cpp/ref/names/rtl/c-ByteSequence.html | 243 +
content/udk/cpp/ref/names/rtl/c-IReference.html | 110 +
content/udk/cpp/ref/names/rtl/c-Logfile.html | 212 +
content/udk/cpp/ref/names/rtl/c-OLocale.html | 349 +
content/udk/cpp/ref/names/rtl/c-OString.html | 474 +
content/udk/cpp/ref/names/rtl/c-OStringBuffer.html | 421 +
content/udk/cpp/ref/names/rtl/c-OStringHash.html | 112 +
content/udk/cpp/ref/names/rtl/c-OUString.html | 544 +
.../udk/cpp/ref/names/rtl/c-OUStringBuffer.html | 435 +
content/udk/cpp/ref/names/rtl/c-OUStringHash.html | 112 +
content/udk/cpp/ref/names/rtl/c-Reference.html | 234 +
content/udk/cpp/ref/names/rtl/c-TestResult.html | 168 +
content/udk/cpp/ref/names/rtl/c-Uri.html | 120 +
.../ref/names/rtl/e-__ByteSequence_NoAcquire.html | 68 +
.../ref/names/rtl/e-__ByteSequence_NoDefault.html | 67 +
content/udk/cpp/ref/names/rtl/index.html | 159 +
content/udk/cpp/ref/names/rtl/o-ustring.hxx.html | 210 +
content/udk/cpp/ref/names/s_Anonymous__15/d.html | 63 +
content/udk/cpp/ref/names/s_Anonymous__15/o.html | 39 +
content/udk/cpp/ref/names/s_Anonymous__20/d.html | 95 +
content/udk/cpp/ref/names/s_Anonymous__20/o.html | 39 +
content/udk/cpp/ref/names/s_Anonymous__22/d.html | 55 +
content/udk/cpp/ref/names/s_Anonymous__22/o.html | 39 +
.../names/store/OStoreDirectory/c-traveller.html | 110 +
.../udk/cpp/ref/names/store/OStoreDirectory/d.html | 53 +
.../udk/cpp/ref/names/store/OStoreDirectory/o.html | 646 +
.../names/store/OStoreDirectory/t-iterator.html | 57 +
.../names/store/OStoreDirectory/traveller/d.html | 39 +
.../names/store/OStoreDirectory/traveller/o.html | 98 +
content/udk/cpp/ref/names/store/OStoreFile/d.html | 53 +
content/udk/cpp/ref/names/store/OStoreFile/o.html | 1047 ++
.../udk/cpp/ref/names/store/OStoreStream/d.html | 53 +
.../udk/cpp/ref/names/store/OStoreStream/o.html | 757 ++
.../udk/cpp/ref/names/store/c-OStoreDirectory.html | 225 +
content/udk/cpp/ref/names/store/c-OStoreFile.html | 241 +
.../udk/cpp/ref/names/store/c-OStoreStream.html | 211 +
content/udk/cpp/ref/names/store/index.html | 70 +
content/udk/cpp/ref/names/t-HANDLE.html | 47 +
content/udk/cpp/ref/names/t-PVOID.html | 47 +
content/udk/cpp/ref/names/t-RTFieldAccess.html | 74 +
content/udk/cpp/ref/names/t-RegAccessMode.html | 58 +
content/udk/cpp/ref/names/t-RegHandle.html | 51 +
content/udk/cpp/ref/names/t-RegKeyHandle.html | 51 +
content/udk/cpp/ref/names/t-RegValue.html | 51 +
content/udk/cpp/ref/names/t-TimeValue.html | 47 +
content/udk/cpp/ref/names/t-TypeReaderImpl.html | 51 +
content/udk/cpp/ref/names/t-TypeWriterImpl.html | 51 +
content/udk/cpp/ref/names/t-cuno_ErrorCode.html | 47 +
content/udk/cpp/ref/names/t-oslAddrFamily.html | 47 +
content/udk/cpp/ref/names/t-oslCondition.html | 47 +
.../udk/cpp/ref/names/t-oslConditionResult.html | 47 +
content/udk/cpp/ref/names/t-oslDateTime.html | 47 +
content/udk/cpp/ref/names/t-oslDescriptorFlag.html | 47 +
content/udk/cpp/ref/names/t-oslDescriptorType.html | 47 +
content/udk/cpp/ref/names/t-oslDirectory.html | 47 +
content/udk/cpp/ref/names/t-oslDirectoryItem.html | 47 +
content/udk/cpp/ref/names/t-oslFileError.html | 47 +
content/udk/cpp/ref/names/t-oslFileHandle.html | 47 +
content/udk/cpp/ref/names/t-oslFileStatus.html | 47 +
content/udk/cpp/ref/names/t-oslFileType.html | 47 +
content/udk/cpp/ref/names/t-oslHostAddr.html | 52 +
.../udk/cpp/ref/names/t-oslInterlockedCount.html | 47 +
content/udk/cpp/ref/names/t-oslModule.html | 47 +
content/udk/cpp/ref/names/t-oslMutex.html | 47 +
content/udk/cpp/ref/names/t-oslPipe.html | 47 +
content/udk/cpp/ref/names/t-oslPipeError.html | 47 +
content/udk/cpp/ref/names/t-oslPipeOptions.html | 47 +
content/udk/cpp/ref/names/t-oslProcess.html | 59 +
content/udk/cpp/ref/names/t-oslProcessData.html | 47 +
content/udk/cpp/ref/names/t-oslProcessError.html | 47 +
.../udk/cpp/ref/names/t-oslProcessExitCode.html | 47 +
.../udk/cpp/ref/names/t-oslProcessIdentifier.html | 47 +
content/udk/cpp/ref/names/t-oslProcessInfo.html | 47 +
content/udk/cpp/ref/names/t-oslProcessOption.html | 47 +
content/udk/cpp/ref/names/t-oslProfile.html | 47 +
content/udk/cpp/ref/names/t-oslProfileOption.html | 47 +
content/udk/cpp/ref/names/t-oslProtocol.html | 47 +
content/udk/cpp/ref/names/t-oslSecurity.html | 57 +
content/udk/cpp/ref/names/t-oslSecurityError.html | 47 +
content/udk/cpp/ref/names/t-oslSemaphore.html | 47 +
content/udk/cpp/ref/names/t-oslSignal.html | 47 +
content/udk/cpp/ref/names/t-oslSignalAction.html | 47 +
content/udk/cpp/ref/names/t-oslSignalHandler.html | 47 +
content/udk/cpp/ref/names/t-oslSignalInfo.html | 47 +
content/udk/cpp/ref/names/t-oslSocket.html | 52 +
content/udk/cpp/ref/names/t-oslSocketAddr.html | 52 +
.../udk/cpp/ref/names/t-oslSocketDirection.html | 47 +
content/udk/cpp/ref/names/t-oslSocketError.html | 47 +
content/udk/cpp/ref/names/t-oslSocketMsgFlag.html | 47 +
content/udk/cpp/ref/names/t-oslSocketOption.html | 47 +
.../udk/cpp/ref/names/t-oslSocketOptionLevel.html | 47 +
content/udk/cpp/ref/names/t-oslSocketResult.html | 47 +
content/udk/cpp/ref/names/t-oslSocketSet.html | 52 +
content/udk/cpp/ref/names/t-oslSocketType.html | 47 +
content/udk/cpp/ref/names/t-oslThread.html | 53 +
.../udk/cpp/ref/names/t-oslThreadIdentifier.html | 47 +
content/udk/cpp/ref/names/t-oslThreadKey.html | 47 +
content/udk/cpp/ref/names/t-oslThreadPriority.html | 47 +
.../udk/cpp/ref/names/t-oslVolumeDeviceHandle.html | 47 +
content/udk/cpp/ref/names/t-oslVolumeInfo.html | 47 +
.../udk/cpp/ref/names/t-rtlBootstrapHandle.html | 47 +
content/udk/cpp/ref/names/t-rtlCipher.html | 52 +
.../udk/cpp/ref/names/t-rtlCipherAlgorithm.html | 52 +
.../udk/cpp/ref/names/t-rtlCipherDirection.html | 52 +
content/udk/cpp/ref/names/t-rtlCipherError.html | 52 +
content/udk/cpp/ref/names/t-rtlCipherMode.html | 52 +
content/udk/cpp/ref/names/t-rtlDigest.html | 52 +
.../udk/cpp/ref/names/t-rtlDigestAlgorithm.html | 52 +
content/udk/cpp/ref/names/t-rtlDigestError.html | 52 +
content/udk/cpp/ref/names/t-rtlRandomError.html | 52 +
content/udk/cpp/ref/names/t-rtlRandomPool.html | 52 +
content/udk/cpp/ref/names/t-rtl_Locale.html | 47 +
content/udk/cpp/ref/names/t-rtl_ModuleCount.html | 47 +
.../cpp/ref/names/t-rtl_StandardModuleCount.html | 47 +
content/udk/cpp/ref/names/t-rtl_String.html | 47 +
content/udk/cpp/ref/names/t-rtl_TestResult.html | 47 +
.../udk/cpp/ref/names/t-rtl_TestResult_vtable.html | 47 +
content/udk/cpp/ref/names/t-rtl_TextEncoding.html | 60 +
.../udk/cpp/ref/names/t-rtl_TextEncodingInfo.html | 47 +
.../cpp/ref/names/t-rtl_TextToUnicodeContext.html | 52 +
.../ref/names/t-rtl_TextToUnicodeConverter.html | 52 +
.../cpp/ref/names/t-rtl_UnicodeToTextContext.html | 52 +
.../ref/names/t-rtl_UnicodeToTextConverter.html | 52 +
content/udk/cpp/ref/names/t-rtl_UriCharClass.html | 47 +
.../cpp/ref/names/t-rtl_UriDecodeMechanism.html | 47 +
.../cpp/ref/names/t-rtl_UriEncodeMechanism.html | 47 +
content/udk/cpp/ref/names/t-rtl_cmpstate.html | 47 +
content/udk/cpp/ref/names/t-rtl_funcstate.html | 47 +
content/udk/cpp/ref/names/t-rtl_uString.html | 47 +
content/udk/cpp/ref/names/t-sal_Bool.html | 47 +
content/udk/cpp/ref/names/t-sal_Char.html | 47 +
content/udk/cpp/ref/names/t-sal_Handle.html | 47 +
content/udk/cpp/ref/names/t-sal_Int16.html | 47 +
content/udk/cpp/ref/names/t-sal_Int32.html | 47 +
content/udk/cpp/ref/names/t-sal_Int64.html | 47 +
content/udk/cpp/ref/names/t-sal_Int8.html | 47 +
content/udk/cpp/ref/names/t-sal_Sequence.html | 47 +
content/udk/cpp/ref/names/t-sal_Size.html | 47 +
content/udk/cpp/ref/names/t-sal_Unicode.html | 47 +
content/udk/cpp/ref/names/t-sal_sChar.html | 47 +
content/udk/cpp/ref/names/t-sal_uChar.html | 47 +
content/udk/cpp/ref/names/t-sal_uInt16.html | 47 +
content/udk/cpp/ref/names/t-sal_uInt32.html | 47 +
content/udk/cpp/ref/names/t-sal_uInt64.html | 47 +
content/udk/cpp/ref/names/t-sal_uInt8.html | 47 +
content/udk/cpp/ref/names/t-storeAccessMode.html | 52 +
.../udk/cpp/ref/names/t-storeDirectoryHandle.html | 52 +
content/udk/cpp/ref/names/t-storeError.html | 52 +
content/udk/cpp/ref/names/t-storeFileHandle.html | 52 +
content/udk/cpp/ref/names/t-storeFindData.html | 52 +
content/udk/cpp/ref/names/t-storeHandle.html | 52 +
content/udk/cpp/ref/names/t-storeStreamHandle.html | 52 +
.../ref/names/t-typelib_ArrayTypeDescription.html | 47 +
.../ref/names/t-typelib_CompoundMember_Init.html | 47 +
.../names/t-typelib_CompoundTypeDescription.html | 47 +
.../ref/names/t-typelib_EnumTypeDescription.html | 47 +
.../names/t-typelib_IndirectTypeDescription.html | 47 +
...-typelib_InterfaceAttributeTypeDescription.html | 47 +
.../t-typelib_InterfaceMemberTypeDescription.html | 47 +
.../t-typelib_InterfaceMethodTypeDescription.html | 47 +
.../names/t-typelib_InterfaceTypeDescription.html | 47 +
.../cpp/ref/names/t-typelib_MethodParameter.html | 47 +
.../cpp/ref/names/t-typelib_Parameter_Init.html | 47 +
content/udk/cpp/ref/names/t-typelib_TypeClass.html | 47 +
.../cpp/ref/names/t-typelib_TypeDescription.html | 47 +
.../names/t-typelib_TypeDescriptionReference.html | 47 +
content/udk/cpp/ref/names/t-typelib_Uik.html | 47 +
.../ref/names/t-typelib_UnionTypeDescription.html | 47 +
.../udk/cpp/ref/names/t-typelib_Union_Init.html | 47 +
content/udk/cpp/ref/names/t-uno_Any.html | 47 +
content/udk/cpp/ref/names/t-uno_Environment.html | 47 +
.../udk/cpp/ref/names/t-uno_ExtEnvironment.html | 67 +
content/udk/cpp/ref/names/t-uno_Interface.html | 47 +
content/udk/cpp/ref/names/t-uno_Mapping.html | 47 +
content/udk/cpp/ref/names/t-uno_Sequence.html | 47 +
content/udk/cpp/ref/names/t-uno_ThreadPool.html | 47 +
content/udk/cpp/ref/names/uno_Context/d.html | 39 +
content/udk/cpp/ref/names/uno_Context/o.html | 39 +
content/udk/documentation_structure.html | 110 +
content/udk/faq.html | 12 +
content/udk/index.html | 41 +
.../examples/wsproxy/component_description.html | 725 ++
.../udk/java/man/AccessingOfficeFromRemote.html | 364 +
content/udk/java/man/UnoApp.html | 129 +
content/udk/java/man/connectors_acceptos.html | 20 +
content/udk/java/man/conventions.html | 52 +
content/udk/java/man/faq.html | 27 +
content/udk/java/man/index.html | 151 +
content/udk/java/man/java_component_howto.html | 479 +
content/udk/java/man/java_uno_bridge.html | 26 +
content/udk/java/man/javaloader.html | 121 +
content/udk/java/man/javavm.html | 32 +
content/udk/java/man/jurt.html | 383 +
content/udk/java/man/lifecycle.html | 111 +
content/udk/java/man/map_idl_to_java.html | 613 +
content/udk/java/man/regcomp.html | 27 +
content/udk/java/man/register_java_components.html | 80 +
content/udk/java/man/ridl.html | 197 +
content/udk/java/man/sandbox.html | 32 +
content/udk/java/man/style.html | 31 +
content/udk/java/man/typelibrary.html | 41 +
content/udk/java/man/types.html | 12 +
content/udk/java/ref/allclasses-frame.html | 129 +
content/udk/java/ref/allclasses-noframe.html | 129 +
.../ref/com/sun/star/comp/helper/Bootstrap.html | 298 +
.../com/sun/star/comp/helper/ComponentContext.html | 371 +
.../star/comp/helper/ComponentContextEntry.html | 298 +
.../star/comp/helper/RegistryServiceFactory.html | 378 +
.../sun/star/comp/helper/SharedLibraryLoader.html | 407 +
.../com/sun/star/comp/helper/package-frame.html | 42 +
.../com/sun/star/comp/helper/package-summary.html | 155 +
.../ref/com/sun/star/comp/helper/package-tree.html | 135 +
.../com/sun/star/lib/uno/helper/ComponentBase.html | 498 +
.../star/lib/uno/helper/InterfaceContainer.html | 1012 ++
.../uno/helper/MultiTypeInterfaceContainer.html | 350 +
.../com/sun/star/lib/uno/helper/PropertySet.html | 1490 +++
.../ref/com/sun/star/lib/uno/helper/UnoUrl.html | 422 +
.../com/sun/star/lib/uno/helper/WeakAdapter.html | 324 +
.../ref/com/sun/star/lib/uno/helper/WeakBase.html | 409 +
.../com/sun/star/lib/uno/helper/package-frame.html | 46 +
.../sun/star/lib/uno/helper/package-summary.html | 164 +
.../com/sun/star/lib/uno/helper/package-tree.html | 143 +
.../java/ref/com/sun/star/tools/uno/DumpType.html | 282 +
.../sun/star/tools/uno/DumpTypeDescription.html | 319 +
.../java/ref/com/sun/star/tools/uno/RegComp.html | 266 +
.../java/ref/com/sun/star/tools/uno/UnoApp.html | 545 +
.../ref/com/sun/star/tools/uno/package-frame.html | 40 +
.../com/sun/star/tools/uno/package-summary.html | 148 +
.../ref/com/sun/star/tools/uno/package-tree.html | 144 +
content/udk/java/ref/com/sun/star/uno/Any.html | 363 +
.../java/ref/com/sun/star/uno/AnyConverter.html | 831 ++
content/udk/java/ref/com/sun/star/uno/Ascii.html | 256 +
.../udk/java/ref/com/sun/star/uno/AsciiString.html | 256 +
.../ref/com/sun/star/uno/DeploymentException.html | 277 +
content/udk/java/ref/com/sun/star/uno/Enum.html | 267 +
.../udk/java/ref/com/sun/star/uno/Exception.html | 306 +
content/udk/java/ref/com/sun/star/uno/IBridge.html | 358 +
.../java/ref/com/sun/star/uno/IEnvironment.html | 365 +
.../ref/com/sun/star/uno/IFieldDescription.html | 255 +
.../udk/java/ref/com/sun/star/uno/IMapping.html | 218 +
.../ref/com/sun/star/uno/IMemberDescription.html | 312 +
.../ref/com/sun/star/uno/IMethodDescription.html | 367 +
.../java/ref/com/sun/star/uno/IQueryInterface.html | 267 +
.../ref/com/sun/star/uno/ITypeDescription.html | 466 +
.../ref/com/sun/star/uno/MappingException.html | 300 +
.../ref/com/sun/star/uno/RuntimeException.html | 311 +
.../ref/com/sun/star/uno/SecurityException.html | 277 +
content/udk/java/ref/com/sun/star/uno/Type.html | 631 +
.../udk/java/ref/com/sun/star/uno/TypeClass.html | 1265 ++
content/udk/java/ref/com/sun/star/uno/Uik.html | 352 +
content/udk/java/ref/com/sun/star/uno/Union.html | 289 +
.../udk/java/ref/com/sun/star/uno/UnoRuntime.html | 720 ++
.../java/ref/com/sun/star/uno/WeakReference.html | 267 +
.../udk/java/ref/com/sun/star/uno/XAdapter.html | 284 +
.../java/ref/com/sun/star/uno/XAggregation.html | 259 +
.../ref/com/sun/star/uno/XComponentContext.html | 262 +
.../java/ref/com/sun/star/uno/XCurrentContext.html | 237 +
.../udk/java/ref/com/sun/star/uno/XInterface.html | 205 +
.../java/ref/com/sun/star/uno/XNamingService.html | 289 +
.../udk/java/ref/com/sun/star/uno/XReference.html | 237 +
.../ref/com/sun/star/uno/XUnloadingPreference.html | 237 +
content/udk/java/ref/com/sun/star/uno/XWeak.html | 240 +
.../java/ref/com/sun/star/uno/package-frame.html | 116 +
.../java/ref/com/sun/star/uno/package-summary.html | 295 +
.../java/ref/com/sun/star/uno/package-tree.html | 154 +
content/udk/java/ref/constant-values.html | 377 +
content/udk/java/ref/deprecated-list.html | 181 +
content/udk/java/ref/help-doc.html | 178 +
content/udk/java/ref/index-all.html | 1418 +++
content/udk/java/ref/index.html | 27 +
content/udk/java/ref/logging/allclasses-frame.html | 45 +
.../star/util/logging/DefaultLoggerWrapper.html | 403 +
.../logging/com/sun/star/util/logging/ILogger.html | 324 +
.../logging/com/sun/star/util/logging/Level.html | 465 +
.../com/sun/star/util/logging/LogManager.html | 375 +
.../Logger.LoggerPropertyChangeListener.html | 219 +
.../logging/com/sun/star/util/logging/Logger.html | 657 +
.../com/sun/star/util/logging/Watchdog.html | 293 +
.../sun/star/util/logging/log4jLoggerWrapper.html | 472 +
.../util/logging/log4jLoggerWrapperFactory.html | 219 +
.../com/sun/star/util/logging/log4jPriority.html | 528 +
...gurator.ConfiguratorPropertyChangeListener.html | 219 +
.../util/logging/log4jPropertyConfigurator.html | 327 +
.../com/sun/star/util/logging/package-frame.html | 55 +
.../com/sun/star/util/logging/package-summary.html | 156 +
.../com/sun/star/util/logging/package-tree.html | 123 +
content/udk/java/ref/logging/deprecated-list.html | 91 +
content/udk/java/ref/logging/help-doc.html | 140 +
content/udk/java/ref/logging/index-all.html | 462 +
content/udk/java/ref/logging/index.html | 24 +
content/udk/java/ref/logging/overview-tree.html | 125 +
content/udk/java/ref/logging/packages.html | 28 +
content/udk/java/ref/logging/serialized-form.html | 91 +
content/udk/java/ref/overview-frame.html | 50 +
content/udk/java/ref/overview-summary.html | 144 +
content/udk/java/ref/overview-tree.html | 173 +
content/udk/java/ref/packages.html | 34 +
content/udk/java/ref/serialized-form.html | 241 +
content/udk/project_tools.html | 45 +
content/udk/python/oood/index.html | 333 +
content/udk/python/python-bridge.html | 2072 ++++
content/udk/python/scriptingframework/index.html | 268 +
content/udk/test space.html | 4 +
1157 files changed, 285342 insertions(+)
diff --git a/content/udk/basic/index.html b/content/udk/basic/index.html
new file mode 100644
index 0000000..fbd4bbf
--- /dev/null
+++ b/content/udk/basic/index.html
@@ -0,0 +1,90 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<html>
+ <head>
+ <meta HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
+ <title>Basic in UNO and OpenOffice.org</title>
+ <meta NAME="KEYWORDS" CONTENT="sandbox">
+ </head>
+ <body LINK="#444488" VLINK="#444488" bgcolor="#eeeeff"><A NAME="__Top__"></A>
+
+ <table WIDTH=100% BORDER=0 CELLPADDING=4 CELLSPACING=0>
+ <col WIDTH=75>
+ <tr>
+ <td bgcolor="#666699">
+ <h1 ALIGN=CENTER STYLE="margin-top: 0cm; text-decoration: none">
+ <font COLOR="#ffffff" SIZE=6>Basic in UNO and OpenOffice.org</font>
+ </h1>
+ </td>
+ </tr>
+ </table>
+
+ <P>
+
+ Basic is a scripting language directly integrated in OpenOffice.org.
+ OpenOffice.org is based on the language independent component model
+ <a href="../../common/man/uno.html">UNO</a>. In the moment it's
+ not possible write components in Basic. But already existing
+ components and the complete OpenOffice.org API based on UNO can be
+ accessed from Basic.
+
+ <P>
+
+ The following list contains some sources that explain how Basic
+ can be used for accessing UNO.
+
+<ul>
+
+ <li> The general functionality of StarBasic is described in the
+ OpenOffice.org online help system.</li>
+
+ <li> Description of the UNO/Basic language binding:
+ <a href="http://api.openoffice.org/DevelopersGuide/DevelopersGuide.html">
+ Developers guide</a>
+ , chapter ProfessionalUNO.pdf, paragraph 3.4.4 Basic.
+ This document is part of the UNO Developer
+ Manual. Although only the Basic chapter contains explicit information about UNO
+ programming with Basic, the whole document can also be useful for Basic programmers as
+ a general UNO development overview.</li>
+
+ <li> API related information about the Basic programming language:
+ <a href="http://api.openoffice.org/source/browse/api/devmanual/BasicAndDialogs/UsingBasic.xml">
+ UsingBasic.xml</a> <br>
+ (this DRAFT document will become part of the UNO Developer Manual). * </li>
+
+ <li> The Integrated development Environment used to write Basic programs and to design
+ dialogs the can be used from Basic is described in:
+ <a href="http://api.openoffice.org/source/browse/api/devmanual/BasicAndDialogs/BasicIDE.xml">
+ BasicIDE.xml</a> <br>
+ (this DRAFT document will become part of the UNO Developer Manual). * </li>
+
+ <li> Description of the toolkit controls that are used to create Basic dialogs and the
+ corresponding API:
+ <a href="http://api.openoffice.org/source/browse/api/devmanual/BasicAndDialogs/ToolkitControls.xml">
+ ToolkitControls.xml</a> <br>
+ (this DRAFT document will become part of the UNO Developer Manual). * </li>
+
+ <li> The organisation of Basic libraries and the corresponding API is described in:
+ <a href="http://api.openoffice.org/source/browse/api/devmanual/BasicAndDialogs/BasicLibraries.xml">
+ BasicLibraries.xml</a> <br>
+ (this DRAFT document will become part of the UNO Developer Manual). * </li>
+
+ <li> A simple UNO developers guide can be found here:
+ <a href="http://api.openoffice.org/basic/man/tutorial/tutorial.pdf">
+ Tutorial.pdf</a>. <br>This is an older document and refers to the UNO API in
+ StarOffice 5.2 but in general it's still valid for StarOffice 6.0 / OpenOffice.org.</li>
+</ul>
+
+ <p>
+
+ * All DRAFT documents are stored in a special flat XML format that
+ needs a special
+ <a href="http://api.openoffice.org/servlets/ProjectDownloadList?action=download&dlID=16">
+ filter</a> to read them (for details see
+ <a href="http://api.openoffice.org/source/browse/api/devmanual/guideline.html">
+ guideline.html</a>). The flat XML format doesn't contain pictures but only links to pictures. So also some
+ image files (located in the same cvs directory) may be needed to display the according documents correctly.
+
+ <p>
+
+</body>
+</html>
diff --git a/content/udk/cli/cli-uno.html b/content/udk/cli/cli-uno.html
new file mode 100644
index 0000000..52c85e6
--- /dev/null
+++ b/content/udk/cli/cli-uno.html
@@ -0,0 +1,12 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+"http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+ <meta http-equiv="refresh" content="3; URL=http://wiki.services.openoffice.org/wiki/Uno/CLI" />
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+<p class="Header">Redirecting....</p>
+
+</body>
+</html>
diff --git a/content/udk/common/man/apicppclasses.html b/content/udk/common/man/apicppclasses.html
new file mode 100644
index 0000000..2209752
--- /dev/null
+++ b/content/udk/common/man/apicppclasses.html
@@ -0,0 +1,161 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
+ "http://www.w3.org/TR/html4/loose.dtd">
+<html>
+<head>
+ <title>How to design C++ classes that are part of the SDK
+ salhelper/cppuhelper API</title>
+ <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
+</head>
+<body>
+
+<p>Author: Stephan Bergmann. Last changed: $Date: 2004/10/28 13:05:15 $.</p>
+
+<h1>How to design C++ classes that are part of the SDK
+<code>salhelper</code>/<code>cppuhelper</code> API</h1>
+
+<p>The following list gives instructions how to design a C++ class that shall be
+part of the API of either <code>salhelper</code> or <code>cppuhelper</code>
+(i.e., of any SDK shared library that has a C++ API that is not all-inline).
+The motivating force behind those instructions is to minimize the amount of
+global symbols (especially weak ones). The list also explains exactly which
+symbols corresponding to a class to export on which platform; see
+<a href="http://udk.openoffice.org/common/man/libraryversioning.html"><cite>SDK
+Dynamic Library Versioning</cite></a> for details about adding exported symbols
+to dynamic libraries.</p>
+
+<ol>
+<li>
+<p>Never define inline functions. (Neither explicitly nor
+implicitly, by defining a function within its class. Inline functions,
+especially constructors and destructors, often make it necessary to export
+certain symbols that could otherwise be left unexported.)</p>
+</li>
+<li>
+<p>Make sure that the compiler does not declare any implicit
+functions. (To avoid any implicitly defined inline functions, see point 1.
+Potential implicit functions are default constructors, copy constructors,
+destructors, and copy assignment operators. The easiest way to avoid them is to
+declare a destructor, at least one copy constructor, and at least one copy
+assignment operator for each class; those declared functions that shall not be
+available can be declared private and left undefined.)</p>
+</li>
+<li>
+<p>Define every destructor that is declared. (Even a destructor
+that is declared pure virtual, to avoid any implicitly defined inline functions,
+see point 1.)</p>
+</li>
+<li>
+<p>If a class type (possibly <em>cv</em>-qualified, and possibly
+nested within pointer or reference types) is ever used either</p>
+<ul>
+ <li>as a <em>type-id</em> within a <code>dynamic_cast</code> expression that
+ needs to be evaluated at runtime,</li>
+
+ <li> as the static type of an <em>expression</em> within a
+ <code>dynamic_cast</code> expression that needs to be evaluated at
+ runtime,</li>
+
+ <li>as a <em>type-id</em> within a <code>typeid</code> expression,</li>
+
+ <li>as the static type of an <em>expression</em> within a
+ <code>typeid</code> expression,</li>
+
+ <li>as the static type of an <em>assignment-expression</em> within a
+ <code>throw</code> expression, or</li>
+
+ <li>within the <em>exception-declaration</em> of a <code>catch</code>
+ handler,</li>
+</ul>
+<p>then declare its destructor virtual. (To have a dedicated place where RTTI
+for that class is generated. Since in general you cannot control the ways a
+class is used, the best advice probably is to do this for each class that is
+intended to be either used as an exception or subclassed.)</p>
+</li>
+<li>
+<p>If the destructor of a class is declared virtual, declare the
+destructors of all its base classes virtual. (To have a dedicated place where
+RTTI for the base classes is generated, which is referenced by the RTTI for the
+derived class. Since in general you cannot control the ways a class is used,
+the best advice probably is to do this for each class that is intended to be
+subclassed.)</p>
+</li>
+<li>
+<p>Special symbols to be exported for GCC 3:</p>
+<ul>
+ <li>For each constructor that shall be available outside the dynamic
+ library, export any corresponding <code>C1</code> and <code>C2</code>
+ variant symbols.</li>
+
+ <li>For each destructor that shall be available outside the dynamic library,
+ export any corresponding <code>D0</code>, <code>D1</code>, and
+ <code>D2</code> variant symbols. (The <code>D0</code> variant seems to be
+ never called directly, but only be referenced from the vtable, but that is
+ no guarantee that this will not change in a future GCC version.)</li>
+
+ <li>For each class that is used outside the dynamic library in ways covered
+ by point 4 plus recursive application of point 5, export the
+ corresponding <code>_ZTI</code> and <code>_ZTS</code> symbols. (Strictly
+ speaking, the <code>_ZTS</code> symbol need only be exported if the type is
+ ever used as an incomplete type.)</li>
+
+ <li>It is known that some classes are used in ways covered by point 4
+ plus recursive application of point 5, and those classes have no
+ dedicated place where RTTI for them is generated, and thus weak RTTI symbols
+ are emitted wherever needed (classes affected by this are, for example, the
+ all-inline classes representing UNO exception types, and all-inline
+ exception classes like <code>rtl::MalformedUriException</code>; specifically
+ <em>not</em> affected are the standard exception classes
+ <code>std::bad_alloc</code>, <code>std::bad_cast</code>,
+ <code>std::bad_exception</code>, <code>std::bad_typeid</code>,
+ <code>std::domain_error</code>, <code>std::exception</code>,
+ <code>std::invalid_argument</code>, <code>std::ios_base::failure</code>,
+ <code>std::length_error</code>, <code>std::logic_error</code>,
+ <code>std::out_of_range</code>, <code>std::overflow_error</code>,
+ <code>std::range_error</code>, <code>std::runtime_error</code>, and
+ <code>std::underflow_error</code>, as they all have dedicated places for
+ their RTTI symbols in <code>libstlport_gcc.so</code> or
+ <code>libstdc++.so.5</code>). To make those uses work under GCC 3, all
+ involved load objects have to bind the same definitions of those symbols at
+ runtime. To achieve this, the OOo build environment enforces that
+ <em>all</em> global <code>_ZTI</code> and <code>_ZTS</code> symbols defined
+ within a load object (as either weak or normal symbols) are indeed exported
+ (with version <code>GCC_3_0_0</code>, in case the respective load object
+ uses symbol versioning). This implies that any <code>_ZTI</code> and
+ <code>_ZTS</code> symbols covered by the previous point are always exported
+ with version <code>GCC_3_0_0</code>, which defeats the correct use of
+ versioning for those symbols.</li>
+</ul>
+</li>
+<li>
+<p>Special symbols to be exported for Sun C++ 5:</p>
+<ul>
+ <li>For each constructor that shall be available outside the dynamic
+ library, export any corresponding plain and <code>#Nvariant 1</code>
+ variant symbols.</li>
+
+ <li>For each destructor that shall be available outside the dynamic library,
+ export any corresponding plain and <code>#Nvariant 1</code> variant
+ symbols.</li>
+
+ <li>For each class that is used outside the dynamic library in ways covered
+ by point 4 plus recursive application of point 5, export the
+ corresponding <code>__RTTI__</code> symbols (of which there are three, one
+ for the class itself, one for an unqualified pointer to the class, and one
+ for a <code>const</code>-qualified pointer to the class).</li>
+</ul>
+</li>
+<li>
+<p>Special symbols to be exported for Microsoft Visual C++:</p>
+<ul>
+ <li>For each constructor that shall be available outside the dynamic
+ library, export the corresponding symbol.</li>
+
+ <li>For each destructor that shall be available outside the dynamic library,
+ export the corresponding symbol (do not export any <code>`scalar deleting
+ destructor'</code> or <code>`vector deleting destructor'</code>
+ symbols).</li>
+</ul>
+</ol>
+
+</body>
+</html>
diff --git a/content/udk/common/man/binspec.html b/content/udk/common/man/binspec.html
new file mode 100644
index 0000000..c6ee23b
--- /dev/null
+++ b/content/udk/common/man/binspec.html
@@ -0,0 +1,421 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<HTML>
+<head>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1"/>
+ <TITLE>Binary UNO Specification</TITLE>
+ <META NAME="GENERATOR" CONTENT="StarOffice/5.2 (Win32)"/>
+ <META NAME="CLASSIFICATION" CONTENT="UNO C++ Specification"/>
+ <META NAME="KEYWORDS" CONTENT="UNO,C++,Specification"/>
+<style type="text/css">
+ <!--
+h1 { text-align:center; margin-top: 0.2cm; text-decoration: none; color: #ffffff; font-size: 6; margin-top: 0.2cm}
+h2 { margin-top: 0.2cm; margin-bottom=0.1cm; color: #ffffff;
+ background-color: #666699 }
+li {margin-bottom: 0.2cm;}
+dl {margin-bottom: 0.2cm;}
+dd {margin-bottom: 0.2cm;}
+dt {margin-bottom: 0.2cm;}
+-->
+</style>
+</head>
+<body>
+<TABLE WIDTH=100% BORDER=0 CELLPADDING=4 CELLSPACING=0 BGCOLOR=#666699
+ summary=header>
+<TR>
+ <TD BGCOLOR="#666699">
+
+ <h1> Binary UNO Specification </h1>
+ </TD>
+ <td>
+ <A HREF="http://www.openoffice.org/"><IMG SRC="../../images/open_office_org_logo.gif" NAME="Grafik1" ALT="OpenOffice" ALIGN=right BORDER=0 /></A>
+ <td>
+</TR>
+</TABLE>
+
+<h2> Contents </h2>
+ <DL>
+ <DD><A HREF="#Abstract">Abstract</A> <br/>
+ <A HREF="#TypeSpecification">Type Specification</A><br/>
+ <A HREF="#Interface">Interfaces</A><br/>
+ </DD>
+ </DL>
+
+<h2 id="Abstract"> Abstract </h2>
+
+<P>This document contains the specification of the types mapped from the
+ IDL to binary (C) UNO.
+
+<p>You should be familiar with the document <A HREF="uno_the_idea.html">the
+ idea of UNO</A>. A slight knowledge about interfaces, C/C++, and a background
+ about an object model like COM is helpful.</p>
+
+<h2 id="TypeSpecification"> Type Specification </h2>
+
+<P>All types which can be used in the IDL language are specified in this
+ paragraph. The representation of the types is machine, language, and operating
+ system dependent. The base types are swapped if the processor has little
+ or big-endian format. The size of the types may vary depending on the
+ processor bus size. The size of types may depend on the operating system.
+ Another problem is the alignment of data structures: the alignment is
+ processor and bus dependent. Alignment is defined through the following
+ algorithm:</P>
+
+<P>Structure members are stored sequentially by the order in which they are
+declared. Every data object has an <I>alignment-requirement</I>. For
+structures, the requirement is the largest of its members. Every object then
+has an allocated <I>offset</I> so that</P>
+
+<pre>
+ <i>offset</i> <b>%</b> <i>alignment-requirement</i> <b>==</b> 0
+</pre>
+
+<P>If it is possible that the maximum alignment can be restricted (e.g.
+Microsoft Visual C++ compiler) then the maximum alignment is set to 8. Under
+this condition the alignment is set to</p>
+
+<pre>
+ min( <i>n</i>, <b>sizeof</b>( <i>item</i> ) ).
+</pre>
+
+<p>The size is rounded up to the largest integral base type.</P>
+
+ <P>The following table shows the IDL type, size, and layout:</P>
+
+ <TABLE BORDER=1 CELLPADDING=5 CELLSPACING=0 summary="UNO types and thier mapping">
+ <COL WIDTH=20%/> <COL WIDTH=40%/> <COL WIDTH=40%/> <THEAD>
+ <TR VALIGN=top>
+ <TH WIDTH=128>
+ <P>IDL Type</P>
+ </TH>
+ <TH>
+ <P>32 Bit UNO</P>
+ </TH>
+ <TH>
+ <P>64 Bit UNO</P>
+ </TH>
+ </TR>
+ </THEAD> <TBODY>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>byte</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Signed 8 Bit (sal_Int8)</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Signed 8 Bit (sal_Int8)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>short</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Signed 16 Bit (sal_Int16)</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Signed 16 Bit (sal_Int16)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>unsigned short</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Unsigned 16 Bit (sal_uInt16)</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Unsigned 16 Bit (sal_uInt16)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>long</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Signed 32 Bit (sal_Int32)</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Signed 32 Bit (sal_Int32)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>unsigned long</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Unsigned 32 Bit (sal_uInt32)</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Unsigned 32 Bit (sal_uInt32)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>hyper</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Signed 64 Bit (sal_Int64)</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Signed 64 Bit (sal_Int64)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>unsigned hyper</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Unsigned 64 Bit (sal_uInt64)</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Unsigned 64 Bit (sal_uInt64)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>float</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Processor dependent: Intel, Sparc = IEEE float (float)</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Processor dependent: Intel, Sparc = IEEE float (float)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>double</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Processor dependent: Intel, Sparc = IEEE double (double)</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>Processor dependent: Intel, Sparc = IEEE double (double)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>enum</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>A 32 bit value</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>A 32 bit value</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>boolean</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>A 8 bit value (sal_Bool)</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>A 8 bit value (sal_Bool)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>char</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>16 Bit Unicode (sal_UniCode)</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>16 Bit Unicode (sal_UniCode)</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>string</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>A pointer to <a
+ href="../../cpp/ref/names/c-_rtl_uString.html"
+ >rtl_uString struct</a></P>
+ </TD>
+ <TD>
+ <P ALIGN=center>A pointer to <a
+ href="../../cpp/ref/names/c-_rtl_uString.html"
+ >rtl_uString struct</a></P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>struct</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>The struct contains the members in the order of their
+ declaration. The memory layout is described at the beginning of
+ this section. </P>
+ </TD>
+ <TD>
+ <P ALIGN=center>The struct contains the members in the order of the
+ declaration. The memory layout is described at the beginning of
+ this section. </P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>union (unsupported for now)</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>The size is 8+ size of the largest type. The first
+ 64 bit values denotes the discriminant.</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>The size is 8+ size of the largest type. The first
+ 64 bit values denotes the discriminant.</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>sequence</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>A pointer to <a
+ href="../../cpp/ref/names/c-_sal_Sequence.html"
+ >sal_Sequence struct</a> directly appending the elements.</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>A pointer to <a
+ href="../../cpp/ref/names/c-_sal_Sequence.html"
+ >sal_Sequence struct</a> directly appending the elements.</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>exception</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>is struct</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>is struct</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>interface</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>A pointer to <a
+ href="../../cpp/ref/names/c-_uno_Interface.html"
+ >uno_Interface struct</a>.</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>A pointer to <a
+ href="../../cpp/ref/names/c-_uno_Interface.html"
+ >uno_Interface struct</a>.</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>any</P>
+ </TD>
+ <TD>
+ <P ALIGN=center><a
+ href="../../cpp/ref/names/c-_uno_Any.html"
+ >uno_Any struct</a>:</P>
+ <p><em>Any</em>s cannot be nested, i.e. no <em>any</em> can contain an
+ <em>any</em>!</P>
+ </TD>
+ <TD>
+ <P ALIGN=center><a
+ href="../../cpp/ref/names/c-_uno_Any.html"
+ >uno_Any struct</a>:</P>
+ <p><em>Any</em>s cannot be nested, i.e. no <em>any</em> can contain an
+ <em>any</em>!</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>type</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>A pointer to <a
+ href="../../cpp/ref/names/c-_typelib_TypeDescriptionReference.html"
+ >typelib_TypeDescriptionReference struct</a>.</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>A pointer to <a
+ href="../../cpp/ref/names/c-_typelib_TypeDescriptionReference.html"
+ >typelib_TypeDescriptionReference struct</a>.</P>
+ </TD>
+ </TR>
+ <TR VALIGN=top>
+ <TD>
+ <P ALIGN=center>void</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>No memory representation</P>
+ </TD>
+ <TD>
+ <P ALIGN=center>No memory representation</P>
+ </TD>
+ </TR>
+ </TBODY>
+ </TABLE>
+
+ <P>Remarks:</P>
+
+ <UL>
+ <LI>
+ <P>16 Bit UNO is not supported</P>
+ </UL>
+
+<h2 id="Interface"> Interfaces </h2>
+<P>All interfaces are derived from the interface
+<a href="http://api.openoffice.org/common/ref/com/sun/star/uno/XInterface.html">com.sun.star.uno.XInterface</a>.
+This interface is specified in the IDL language:</P>
+
+<pre>
+interface XInterface
+{
+ any queryInterface( [in] type aType );
+ [oneway] void acquire();
+ [oneway] void release();
+};
+</pre>
+
+<p>In contrast to C++ vtable calling, binary UNO calls on a generic dispatcher
+function to perform calls on interfaces.</p>
+
+<pre>
+typedef void (SAL_CALL * uno_DispatchMethod)(
+ uno_Interface * pUnoI,
+ const typelib_TypeDescription * pMemberType,
+ void * pReturn,
+ void * pArgs[],
+ uno_Any ** ppException );
+
+/** The binary C uno interface description. */
+typedef struct _uno_Interface
+{
+ void (SAL_CALL * acquire)( uno_Interface * pInterface );
+ void (SAL_CALL * release)( uno_Interface * pInterface );
+ uno_DispatchMethod pDispatcher;
+} uno_Interface;
+</pre>
+
+<p>The lifetime of interfaces are controlled by acquire() and release().
+ Beware that the dispatch function expects an array of pointers to the parameter values (pArgs),
+ which is for interfaces uno_Interface ** (pointer to interface reference
+ storing an acquired pointer to the uno_Interface struct).
+ To signal, that no exception has to be thrown, *ppException has to set to 0 before
+ returning.
+
+<table summary=footer>
+ <TR>
+ <TD WIDTH=50% BGCOLOR="#666699">
+ <P><FONT COLOR="#ffffff"> Author: <A HREF="mailto:daniel.boelzle@germany.sun.com"><FONT COLOR="#ffffff">Daniel
+ Bölzle</FONT></A> ($Date: 2004/11/27 05:48:04 $)<br/>
+ <I>Copyright 2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.</I></FONT>
+ </P>
+ </TD>
+ </TR>
+</TABLE>
+</body>
+</HTML>
diff --git a/content/udk/common/man/bridge.html b/content/udk/common/man/bridge.html
new file mode 100644
index 0000000..b424de5
--- /dev/null
+++ b/content/udk/common/man/bridge.html
@@ -0,0 +1,11 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+"http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="refresh" content="3; URL=http://wiki.services.openoffice.org/wiki/Uno/Article/About_Bridges"/>
+ <meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+ </head>
+ <body>
+ <p class="Header">Redirecting....</p>
+ </body>
+</html>
diff --git a/content/udk/common/man/componentmodel.html b/content/udk/common/man/componentmodel.html
new file mode 100644
index 0000000..33887e1
--- /dev/null
+++ b/content/udk/common/man/componentmodel.html
@@ -0,0 +1,178 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
+ "http://www.w3.org/TR/html4/loose.dtd">
+<html>
+<head>
+ <title>UNO Component Model</title>
+ <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
+</head>
+<body>
+
+<table width="100%" border="0" cellspacing="0" cellpadding="4">
+ <tr><td bgcolor="#666699">
+ <h1 align="center" style="margin-top: 0in; text-decoration: none"><!--
+ --><a href="http://www.openoffice.org"><img
+ src="../../images/open_office_org_logo.gif" alt="OpenOffice.org"
+ align="right" border="0"></a><font color="White">UNO Component
+ Model</font></h1>
+ </td></tr>
+</table>
+<hr noshade size="3"/>
+
+<h1>Conceptual Model</h1>
+
+<p>We use the term “component” here in a very limited, well defined
+sense. Unfortunately, within the broader field, and even within UNO itself, the
+term is also used with other meanings, typically to mean some form of collection
+of what is here called components.</p>
+
+<p>A <dfn>UNO component</dfn> is the smallest unit in the UNO component model.
+A UNO component is a software artifact that has the following properties:</p>
+<ul>
+ <li>A component has a <dfn>component implementation name</dfn>, by which it
+ is known to its deployment environment. Component implementation names are
+ always relative to a given deployment environment.</li>
+
+ <li>To describe the interface that clients of a component can use, the
+ component links to a <dfn>component client interface</dfn> via a
+ <dfn>component client interface name</dfn>.</li>
+
+ <li>One of the more obvious requirements a component has on its deployment
+ environment is that the component itself will be a client of other
+ components, which it uses internally in its implementation. To describe
+ this requirement, a component has <dfn>component dependencies</dfn>, a map
+ from <dfn>component instantiation names</dfn> to <dfn>component client
+ interface names</dfn>.<br/>
+ The component dependencies only cover <em>static</em> dependencies. A
+ component may also have <em>dynamic</em> dependencies; for example, at
+ runtime an instance of that component may take an input <var>N</var>,
+ compute a service instantiation name <var>N</var>′ from it, and
+ expect to obtain a component instance with a certain component client
+ interface when passing <var>N</var>′ to the component manager.</li>
+</ul>
+
+<p>A <dfn>component client interface</dfn> is a set of UNO interface types
+(referenced by their—globally unique—names), together with a marker
+for each interface type, denoting it as either <dfn>mandatory</dfn> or
+<dfn>optional</dfn>, and semantic constraints on the functionality of those
+interface types and the runtime presence of any optional interface types. There
+is one constraint on the set of interface types: no optional interface type from
+the set may be an (indirect) base type of any mandatory interface type from the
+set.</p>
+
+<p>Each component client interfaces is associated with a globally unique
+<dfn>component client interface name</dfn>. This association must be globally
+unique; otherwise, clients of a component (who describe their expectations of
+the component by means of a component client interface name) could not be sure
+that, at runtime, they receive a component instance that meets their
+expectations. (This requirement of globally unique names for component client
+interfaces is the same as for named UNO types.)</p>
+
+<p>At runtime, instances of UNO components can be obtained from a <dfn>component
+manager</dfn>. The component instances are UNO objects that behave according to
+their respective component client interfaces. A component manager works based
+on <dfn>component instantiation names</dfn>. Each code that uses a component
+manager must document what component instances (adhering to which component
+client interfaces) it expects to obtain from the component manager, with which
+component instantiation names. Throughout the lifetime of a component instance,
+that instance has access to a certain component manager; what other component
+instances the instance itself expects to obtain from that component manager is
+documented by the component's component dependencies (but note that this only
+covers the component's static dependencies).</p>
+
+<h1>How UNO Implements the Conceptual Model</h1>
+
+<p>Components are often also called <dfn>services</dfn> in UNO. The conceptual
+component client interfaces are implemented as UNOIDL service descriptions,
+whose names serve as the conceptual component client interface names. The
+conceptual properties of components are represented in UNO as follows:</p>
+<ul>
+ <li>The conceptual component implementation name breaks up into two parts.
+ First, each component has an implementation name, which must be unique
+ within the deployment environment (see
+ <code>com.sun.star.lang.XServiceInfo.getImplemenationName</code>). Second,
+ the <code>services.rdb</code> registry associates each implementation name
+ with an activator (e.g., <code>com.sun.star.loader.SharedLibrary</code>) and
+ an activator-dependent location (e.g., a platform-dependent shared library
+ pathname, in case of the <code>com.sun.star.loader.SharedLibrary</code>
+ loader).</li>
+
+ <li>The association of a component with a component client interface is
+ again done in the <code>services.rdb</code> registry, by associating each
+ implementation name with one or more UNOIDL service description names.</li>
+
+ <li>The conceptual component dependencies are not actually recorded for a
+ UNO component. Rather, they can implicitly be derived from the component's
+ code. However, with the XML module description approach, they would be
+ recorded as (optional) <code>service-dependency</code> elements. Each
+ <code>service-dependency</code> element contains the name of a UNOIDL
+ service description, serving as both the component instantiation name and
+ the component client interface name.</li>
+</ul>
+
+<p>A UNOIDL service description appears to be richer than a corresponding
+conceptual component client interface (which, after all, is little more than a
+set of UNO interface types with associated semantic constraints). But all of
+this additional richness can be reduced to syntactic sugar:</p>
+<ul>
+ <li>A UNOIDL service description implicitly adds
+ <code>com.sun.star.uno.XWeak</code>,
+ <code>com.sun.star.lang.XTypeProvider</code>, and
+ <code>com.sun.star.lang.XServiceInfo</code> to the set of interface types,
+ with respective constraints on their functionality (e.g.,
+ <code>com.sun.star.lang.XTypeProvider.getTypes</code> must return all the
+ mandatory interface types covered by the service description).</li>
+
+ <li>A UNOIDL service description can contain property declarations. These
+ map to functional constraints on an explicitly or implicitly exported
+ interface type like <code>com.sun.star.beans.XPropertySet</code>. For
+ example, if a UNOIDL service description contains the property declaration
+ <code>[property] long P</code>, and exports the mandatory interface type
+ <code>com.sun.star.beans.XPropertySet</code>, then there is the functional
+ constraint that a call to <code>XPropertySet.getPropertyValue("P")</code>
+ returns an <code>ANY</code> value of type <code>LONG</code>.</li>
+
+ <li>A UNOIDL service description can contain other service descriptions,
+ marked as either mandatory or optional. This can be considered a textual
+ inclusion mechanism (the contents of the contained service description is
+ copied into the containing service description, marking all copied entities
+ as optional in case the contained service description was marked as
+ optional), together with possible functional constraints on the resulting
+ component client interface (e.g., if an optional included service
+ description exported two mandatory interface types, then
+ <code>com.sun.star.lang.XTypeProvider.getTypes</code> at runtime must return
+ either both of them or neither of them).</li>
+</ul>
+
+<p>In UNO, the conceptual component managers are instances of
+<code>com.sun.star.lang.ServiceManager</code>. UNO does not distinguish between
+the conceptional component client interface names and component instantiation
+names—the names of UNOIDL service descriptions are used for both
+cases.</p>
+
+<p>When a component instance is created at runtime, it is passed a
+<code>com.sun.star.uno.XComponentContext</code>, through which it has access to
+a <code>com.sun.star.lang.ServiceManager</code>. The guarantee that this
+<code>ServiceManager</code> fulfils the component's component dependencies is
+indirect and weak: since component instantiation names are (globally unique)
+names of UNOIDL service descriptions, which in turn are the same as component
+client interface names, it is guaranteed that if a <code>ServiceManager</code>
+returns any component instance at all for a given component instantiation name
+from the component dependencies, then that instance will adhere to the
+corresponding component client interface from the component dependencies.
+However, there is no guarantee that the <code>ServiceManager</code> does not
+return null instead. Also, there is no way to guarantee that a component's
+dynamic dependencies are satisfied.</p>
+
+<table width="100%" border="0" cellspacing="0" cellpadding="4">
+ <tr><td bgcolor="#666699">
+ <p><font color="White">Author:
+ <a href="mailto:stephan.bergmann@sun.com"><font color="White">Stephan
+ Bergmann</font></a> (last modification $Date: 2004/10/28 14:58:24 $).
+ Copyright 2004 <a href="http://www.openoffice.org"><font
+ color="White">OpenOffice.org</font></a> Foundation. All rights
+ reserved.</font></p>
+ </td></tr>
+</table>
+
+</body>
+</html>
diff --git a/content/udk/common/man/componentnames.html b/content/udk/common/man/componentnames.html
new file mode 100644
index 0000000..8c1edf9
--- /dev/null
+++ b/content/udk/common/man/componentnames.html
@@ -0,0 +1,184 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<HTML>
+<head>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
+ <TITLE>Naming UNO Components</TITLE>
+</head>
+<body>
+<TABLE WIDTH="100%" BORDER="0" CELLSPACING="0" CELLPADDING="4">
+ <TR>
+ <TD BGCOLOR="#666699">
+ <H1 ALIGN="CENTER" STYLE="margin-top: 0in; text-decoration: none"><A HREF="http://www.openoffice.org"><IMG SRC="../../../images/open_office_org_logo.gif" ALT="OpenOffice.org" ALIGN="RIGHT" BORDER="0"></A><FONT COLOR="White">Naming UNO Components</FONT></H1>
+ </TD>
+ </TR>
+</TABLE>
+<HR NOSHADE SIZE="3">
+
+
+[This document is intended to become part of the Developers Guide; once that is
+done and available online, this document can be removed again.]
+
+
+<H1>Naming Scheme</H1>
+
+<P>UNO components that come in the form of a shared library (<CODE>.so</CODE> on
+Linux and Solaris, <CODE>.dll</CODE> on Windows, <CODE>.dylib</CODE> on Mac)
+should be named as
+<PRE>
+<VAR><CODE>NAME</CODE></VAR>[<VAR><CODE>VERSION</CODE></VAR>]<!--
+ --><CODE>.uno.</CODE>(<CODE>so</CODE>|<CODE>dll</CODE>|<CODE>dylib</CODE>)
+</PRE>
+that is a descriptive <VAR><CODE>NAME</CODE></VAR>, followed by an optional
+<VAR><CODE>VERSION</CODE></VAR>, followed by the characters
+“<CODE>.uno</CODE>” and the platform-specific extension
+(“<CODE>.so</CODE>”, “<CODE>.dll</CODE>”,
+“<CODE>.dylib</CODE>”, etc.). The optional
+<VAR><CODE>VERSION</CODE></VAR> should be of the form
+<PRE>
+<VAR><CODE>VERSION</CODE></VAR> = <VAR><CODE>MAJOR</CODE></VAR> <!--
+ -->[<CODE>.</CODE><VAR><CODE>MINOR</CODE></VAR> <!--
+ -->[<CODE>.</CODE><VAR><CODE>MICRO</CODE></VAR>]]
+<VAR><CODE>MAJOR</CODE></VAR> = <VAR><CODE>NUMBER</CODE></VAR>
+<VAR><CODE>MINOR</CODE></VAR> = <VAR><CODE>NUMBER</CODE></VAR>
+<VAR><CODE>MICRO</CODE></VAR> = <VAR><CODE>NUMBER</CODE></VAR>
+<VAR><CODE>NUMBER</CODE></VAR> = <CODE>0</CODE> | <!--
+ --><CODE>1</CODE>–<CODE>9</CODE> <CODE>0</CODE>–<CODE>9</CODE>*
+</PRE></P>
+
+<P>How to use the <VAR><CODE>VERSION</CODE></VAR> scheme, if at all, to number
+different versions of a given component shared library (e.g., only using the
+<VAR><CODE>MAJOR</CODE></VAR> and increasing it whenever the code is changed, or
+using all of <VAR><CODE>MAJOR</CODE></VAR>, <VAR><CODE>MINOR</CODE></VAR>, and
+<VAR><CODE>MICRO</CODE></VAR>) is not specified here.</P>
+
+<P>Examples of component shared library names are
+<PRE>
+<CODE>component.uno.so</CODE>
+<CODE>component1.uno.dll</CODE>
+<CODE>component0.1.3.uno.dylib</CODE>
+</PRE></P>
+
+<P>Rationale: The <VAR><CODE>VERSION</CODE></VAR> is optional and is mainly
+intended to be useful to humans (e.g., when communicating to others that a
+certain <VAR><CODE>VERSION</CODE></VAR> of a component has a bug); see below for
+some suggestions when it might be useful to use the optional
+<VAR><CODE>VERSION</CODE></VAR> and when not. The
+<VAR><CODE>VERSION</CODE></VAR> is consistently placed before the
+(platform-specific) extension, never after it; on Linux and Solaris, there is a
+convention to add a version number after the “<CODE>.so</CODE>”, but
+that version number has different semantics from the
+<VAR><CODE>VERSION</CODE></VAR> number used here (in short, such a version
+number changes whenever the shared library's interface changes, but that
+interface of a component shared library—the few functions
+<CODE>component_getFactory</CODE> etc.—never changes).</P>
+
+<P>The “<CODE>.uno</CODE>” is placed next to the platform-specific
+extension to emphasize that this is a special sort of shared library (its shared
+library interface consists of only the few functions
+<CODE>component_getFactory</CODE> etc., and the shared library has to be
+registered with UNO to be useful). As the given naming scheme is only a
+suggestion, there might be violations of the rule where a component shared
+library does not contain “<CODE>.uno</CODE>” in its name.
+Therefore, no tool should build assumptions on whether a shared library name
+contains “<CODE>.uno</CODE>” or not (e.g., when <CODE>pkgchk</CODE>
+installs a <CODE>zip</CODE> file component, it should not simply register with
+UNO all those contained shared libraries that contain
+“<CODE>.uno</CODE>” in their names, but should rather use some other
+mechanism like a manifest file explicitly listing all the contained shared
+libraries that need to be registered).</P>
+
+<P>For UNO components that are not shared libraries (e.g., a Java component
+resulting in a <CODE>jar</CODE> file), it can also be useful to add
+“<CODE>.uno</CODE>” (and the optional
+<VAR><CODE>VERSION</CODE></VAR>) to the component's name (e.g.,
+<CODE>component.uno.jar</CODE>, or <CODE>component1.5.uno.jar</CODE>), for the
+same reasons as for component shared libraries: to emphasize that it is a UNO
+component. Again, this is a suggestion, not a hard rule.</P>
+
+
+<H1>Kinds of Components</H1>
+
+<P>When deciding whether to add an optional <VAR><CODE>VERSION</CODE></VAR> to a
+component shared library's name, it might be useful to consider the following
+kinds of components:</P>
+
+<UL>
+ <LI>Those component shared libraries that are considered part of OOo (part
+ of an OOo installation set, placed into the program directory during setup,
+ and registered during setup). Their versions are already well defined by
+ the version of the installed OOo itself (as they are part of the OOo build).
+ And because adding explicit version strings to such shared libraries might
+ cause maintenance problems within the OOo build process (e.g., the
+ <CODE>scp</CODE> projects refer to a shared library with its complete name,
+ so this would have to be adapted whenever a component's
+ <VAR><CODE>VERSION</CODE></VAR> changes), it might be best to leave the
+ versioning out for this sort of component shared libraries.</LI>
+
+ <LI>Those component shared libraries that are part of a larger component
+ <CODE>zip</CODE> file (installed by <CODE>pkgchk</CODE>). Here, any
+ versioning can be put into the name of the <CODE>zip</CODE> file (e.g.,
+ <CODE>component1.5.zip</CODE>); <CODE>pkgchk</CODE> will unpack the
+ component shared library into a directory path from which the name of the
+ <CODE>zip</CODE> file can be deduced, so a human can always track what
+ version of the component <CODE>zip</CODE> file is in use. So, in this case
+ it might also be sensible to not use the versioning for the component shared
+ libraries.</LI>
+
+ <LI>Those component shared libraries that are not part of a larger component
+ <CODE>zip</CODE> file, but are rather components made up of a single shared
+ library (installed by <CODE>pkgchk</CODE>). In this case, it might well
+ make sense to use the versioning, so that a human can easily track what
+ version of such a component got installed (e.g., to mention it in a bug
+ report).</LI>
+</UL>
+
+
+<H1>Ways Components Can Evolve</H1>
+
+<UL>
+ <LI>A component shared library's interface (the few functions
+ <CODE>component_getFactory</CODE> etc.) is assumed to be stable.</LI>
+
+ <LI>A component's service interface (i.e., the UNO services offered by a
+ component) can change:
+ <UL>
+ <LI>compatibly, by adding a new implementation name, or by adding a new
+ UNO service name to an implementation name;</LI>
+
+ <LI>incompatibly, by removing an implementation name, or by removing a
+ UNO service name from an implementation name;</LI>
+
+ <LI>indirectly compatibly, when one of the named UNO services changes
+ compatibly (by adding additional optional interfaces to it).
+ <STRONG>[TODO: Adding optional interfaces to a service is probably
+ <EM>not</EM> a compatible change, see the mail “Extending
+ Published Services with Optional Interfaces Considered Harmful”
+ from August 14, 2003 at
+ <CODE>dev@udk.openoffice.org</CODE>.]</STRONG></LI>
+ </UL></LI>
+
+ <LI>A component shared library's implementation itself can change (bug
+ fixes). Such changes will typically be compatible, unless a known bug is
+ fixed on whose observable behavior clients of the component depend (which,
+ in effect, considered the bug a feature instead).</LI>
+
+ <LI>A component shared library can change its dependencies on other shared
+ libraries (C/C++ runtime libraries like <CODE>libc.so.6</CODE>,
+ <CODE>libstdc++.so.3.0.1</CODE>, and <CODE>libstlport_gcc.so</CODE>; UNO
+ runtime libraries like <CODE>libcppu.so.3.1.0</CODE> and
+ <CODE>libcppuhelpergcc3.so.3.1.0</CODE>; OOo libraries like
+ <CODE>libsvx644li.so</CODE>). These changes are typically incompatible, as
+ they rely on (compatible or incompatible) changes of the component's
+ environment.</LI>
+</UL>
+
+
+<TABLE WIDTH="100%" BORDER="0" CELLSPACING="0" CELLPADDING="4">
+ <TR>
+ <TD BGCOLOR="#666699">
+ <P><FONT COLOR="White">Author: <A HREF="mailto:stephan.bergmann@sun.com"><FONT COLOR="White">Stephan Bergmann</FONT></A> (Last modification $Date: 2003/08/21 13:27:10 $). Copyright 2003 <A HREF="http://www.openoffice.org"><FONT COLOR="White">OpenOffice.org</FONT></A> Foundation. All Rights Reserved.</FONT></P>
+ </TD>
+ </TR>
+</TABLE>
+</body>
+</HTML>
diff --git a/content/udk/common/man/concept/default_bootstrapping.html b/content/udk/common/man/concept/default_bootstrapping.html
new file mode 100644
index 0000000..faa7332
--- /dev/null
+++ b/content/udk/common/man/concept/default_bootstrapping.html
@@ -0,0 +1,12 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+"http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+ <meta http-equiv="refresh" content="3; URL=http://wiki.services.openoffice.org/wiki/Uno/Binary/Spec/Bootstrapping" />
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+<p class="Header">Redirecting....</p>
+
+</body>
+</html>
diff --git a/content/udk/common/man/concept/micro_deployment.html b/content/udk/common/man/concept/micro_deployment.html
new file mode 100644
index 0000000..286dd64
--- /dev/null
+++ b/content/udk/common/man/concept/micro_deployment.html
@@ -0,0 +1,344 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<HTML>
+<head>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1"/>
+ <TITLE>UNO Micro Deployment</TITLE>
+<style type="text/css">
+ <!--
+h1 { text-align:center; margin-top: 0.2cm; text-decoration: none; color: #ffffff; font-size: 6; margin-top: 0.2cm}
+h2 { margin-top: 0.2cm; margin-bottom=0.1cm; color: #ffffff;
+ background-color: #666699 }
+li {margin-bottom: 0.2cm;}
+dl {margin-bottom: 0.2cm;}
+dd {margin-bottom: 0.2cm; margin-right: 0.6cm;}
+dt {margin-bottom: 0.2cm;}
+-->
+</style>
+</head>
+<body>
+
+<TABLE WIDTH=100% BORDER=0 CELLPADDING=4 CELLSPACING=0 BGCOLOR="#666699"
+ summary="Header">
+<tr>
+ <td>
+ <h1> Bootstrap Arguments and Micro Deployment </h1>
+ </td><td>
+ <A HREF="http://www.openoffice.org/">
+ <IMG SRC="../../../images/open_office_org_logo.gif"
+ NAME="Grafik1"
+ ALT="OpenOffice.org"
+ ALIGN=right
+ HEIGHT=54 BORDER=0/>
+ </A>
+ </TD>
+</tr>
+</table>
+
+<H2>Contents</H2>
+
+ <DL>
+ <DD><A HREF="#Abstract">Abstract</A>
+ <br/>
+ <A HREF="#Micro_Deployment">Micro Deployment</A>
+ <br/>
+ <A HREF="#Bootstrap_Arguments">Bootstrap Arguments</A>
+ <br/>
+ <A HREF="#Application_Arguments">Application Arguments</A>
+ </DD>
+ </DL>
+
+ <H2 id="Abstract"> Abstract </H2>
+ <P>While introducing a simple concept for <a href="uno_default_bootstrapping.html">UNO bootstrapping</a>
+ I noticed that there is a need for a
+ general bootstrap-argument-passing-mechanism. At the moment, we
+ have different locations where some kind of context knowledge for
+ bootstrapping is needed:
+ </P>
+
+<DL>
+ <DT>configuration:</DT>
+ <DD>needs a bootstraprc (bootstrap.ini) to find
+ the appropriate user configuration (e.g., local,
+ portal, remote, etc.)</DD>
+ <DD>currently a special file (bootstraprc) is used</DD>
+ <DT>UNO:</DT>
+ <DD>needs to find the appropriate rdb files to get the needed
+ types and services (see uno default bootstrapping for a
+ more detailed discussion),
+ currently this has to be programmed by hand</DD>
+ <DT>Java:</DT>
+ <DD>needs to know the Java installation to use, this may include
+ a shared library path and needed jar files </DD>
+ </DL>
+
+ <P>Different, but similar concepts are used (e.g., a file with an
+ entry which points to a special directory). First, I would like to
+ unify these concepts and to use one mechanism for bootstrapping. Second,
+ I also would like to be able to configure the bootstrapping via command
+ line arguments or via environment variables (which, for instance,
+ may be set by setsolar). And third, I want not only micro deploy applications
+ but also libraries/subsystems.
+ </P>
+
+
+ <H2><A NAME="Micro_Deployment">Micro Deployment</A></H2>
+ <P>All the different mechanisms used to configure any subsystem have something
+ in common, which I would like to call MICRO DEPLOYMENT. Micro Deployment allows
+ an arbitrary component (application/library) to be configured at deployment time,
+ so that some deployment dependent parameters do not have to be compiled in.
+ </P>
+ <P>For example, a UNO service becomes typically deployed as a shared library. Because it needs
+ some minimal configuration data to work properly, every application which uses the service
+ has to pass this minimal configuration to the service. Using Micro Deployment, this
+ burden vanishes. The installer can create a minimal configuration, which the service
+ will use during runtime. This Micro Deployment is not only usable by shared libraries, but also by
+ executables.
+ </P>
+ <P>
+ The Micro Deployment should be as flexible and as simple as possible. It is not designed
+ to do some complex stuff during startup. Its API decomposes into three parts:
+
+ <UL>
+ <LI>Accessing Deployment/Bootstrap arguments for executables</LI>
+ <LI>Accessing Deployment/Bootstrap arguments for shared objects/shared libraries/subsystems</LI>
+ <LI>Accessing simple command line arguments</LI>
+ </UL>
+
+ <H2><A NAME="Bootstrap_Arguments">Bootstrap Arguments</A></H2>
+ <P>A mechanism to allow differentiated access to bootstrap
+ arguments at the runtime library (RTL) level is needed.</P>
+
+ <H3>Passing Bootstrap Arguments</H3>
+ Bootstrap arguments may be passed to an executable or library, in
+ different ways:
+
+ <UL>
+ <li> parameters may be passed by command line arguments </li>
+ <li> parameters may be passed by an optional .ini/rc file </li>
+ <li> parameters may be passed by environment variables </li>
+ <li> parameters may be passed by inheritance </li>
+ <li> parameters may be passed as default values for 'rtl_bootstrap_get' (see below)</li>
+ </UL>
+
+
+ <H4>Passing Bootstrap Arguments via Command Line </H4>
+ <P>Bootstrap arguments passed via command line must have a special shape to be
+ distinguishable from other command line arguments:
+ </P>
+
+<pre>
+ myapp.bin -env:UNO_SERVICES=service.rdb
+</pre>
+
+ <P>Here, the bootstrap parameter "UNO_SERVICES", is passed as a command line
+ parameter.</P>
+
+
+ <H4>Passing Bootstrap Arguments via .ini/rc Files </H4>
+ Bootstrap arguments may be passed by an optional .ini/rc file.
+ Using the static methods of the Bootstrap class, an .ini/rc file
+ is searched beneath the executable. The .ini/rc file must have
+ the same name as the executable, extended with an '.ini' for
+ windows or an 'rc' for Unix. Any executable extension
+ like '.bin' or '.exe' is stripped from the name:
+
+<pre>
+ echo 'UNO_SERVICES=service.rdb' > myapprc
+ ./myapp.bin
+</pre>
+ <P>
+ The name of the .ini/rc file to use can be overwritten with the
+ 'setIniFileName' function.</P>
+
+ <p>It is also possible to use a custom .ini/rc file name. Particularly, when
+ using micro deployment for shared libraries, this makes sense.</P>
+
+<pre>
+ echo 'UNO_SERVICES=service.rdb' > mylibrc
+ ./an-app-using-mylib.so.bin
+</pre>
+
+
+ <H4>Passing Bootstrap via Inheritance </H4>
+ Bootstrap arguments may be inherited from an executable rc,
+ e.g., when using custom rc file for libraries, this custom
+ rc inherits the bootstrap variables from the executable rc
+ file.
+
+ <H4>Passing Bootstrap Arguments via Environment Variables </H4>
+ Bootstrap arguments may also be passed via environment
+ variables:
+
+<pre>
+ setenv UNO_SERVICES service.rdb
+ ./myapp.bin
+</pre>
+
+ <H3>Accessing Bootstrap Arguments via the RTL (Runtime Library)</H3>
+ To access bootstrap arguments a c and a c++ API exists. I just give
+ some brief code examples of how to use the c++ API. Please have a look
+ at the header files, bootstrap.h and bootstrap.hxx, in sal/inc/rtl for
+ the whole API.
+
+ <P>Accessing an executable bootstrap argument:</P>
+
+ <pre>
+ <font color="#0000FF">int</font> main() {
+ <font color="#0000FF">int</font> result = 0;
+ <font color="#0000FF">OUString</font> argValue;
+
+ <font color="#0000FF">if</font>(Bootstrap::get(
+ <font color="#0000FF">OUString</font>(RTL_CONSTASCII_USTRINGPARAM("aNeededParameter")),
+ argValue)) {
+ fprintf(stderr, "found the parameter, doing something...\n");
+ do_something();
+ }
+ <font color="#0000FF">else</font> {
+ fprintf(stderr, "did not find the parameter, dying...\n");
+ result = -1;
+ }
+
+ <font color="#0000FF">return</font> result;
+ }
+</pre>
+
+<P>Accessing a library bootstrap argument:</P>
+
+<pre>
+ <font color="#0000FF">int</font> aLibraryFunction() {
+ <font color="#0000FF">OUString</font> libraryFileUrl;
+ <font color="#0000FF">Module</font>::getModuleUrl((void *)aLibraryFunction, libraryFileUrl);
+
+ // cut the library extension
+ iniName = libraryFileUrl.copy(0,
+ libraryFileUrl.lastIndexOf((sal_Unicode)'.'));
+ // add the rc file extension
+ iniName += <font color="#0000FF">OUString</font>(RTL_CONSTASCII_USTRINGPARAM(SAL_CONFIGFILE("")));
+
+ <font color="#0000FF">Bootstrap</font> bootstrap(iniName);
+
+ <font color="#0000FF">int</font> result = 0;
+ <font color="#0000FF">OUString</font> argValue;
+ <font color="#0000FF">
+ if</font>(bootstrap.getFrom(<font color="#0000FF">
+ OUString</font>(RTL_CONSTASCII_USTRINGPARAM("aNeededParameter")),
+ argValue))
+ {
+ fprintf(stderr, "found the parameter, doing something...\n");
+ do_something();
+ }
+ <font color="#0000FF">else</font> {
+ fprintf(stderr, "did not find the parameter, dying...\n");
+ result = -1;
+ }
+
+ <font color="#0000FF">return</font> result;
+ }
+</pre>
+
+
+ <H3><a name="misc">Miscellaneous</a></H3>
+ <H4>Conventions for Names of Bootstrap Arguments</H4>
+ Names may only include allowable characters
+ for environment variables. This excludes '.', ' ', ';', ':' and
+ all non-ASCII characters. Names are case insensitive.
+
+ <H4>Range of Values for Bootstrap Arguments</H4>
+ <p>
+ Values may be arbitrary Unicode strings which have to be encoded
+ using UTF8. A simple argument expansion is supported:
+ </p>
+
+ <ul>
+ <li>Allow expansion of variables on the right side of
+ assignments:
+ <br/>
+ MYVAR=hallo
+ <br/>
+ MYMYVAR=${MYVAR}/test
+ <br/>
+ The value of MYMYVAR is 'hallo/test'
+ <br/>
+ </li>
+ <li>
+ Allow indirect expansion of variables through 'osl' profiles:
+ <br/>
+ KEYVALUE=${sversionrc:versions:StarOffice6.0}
+ <br/>
+ The first part of the indirection is the file to use for
+ expansion, the second part is
+ the section, and the third part is the key. After expansion, the
+ variable KEYVALUE has
+ the value of the matching key of the sversionrc.
+ </li>
+ </ul>
+
+<p>The special characters are:</p>
+ <ul>
+ <li> $ - introduces a macro name, which should become expanded </li>
+ <li> \ - quotes the next character </li>
+ <li> \uXXXX - allows the definition of an 16 bit character (Unicode) </li>
+ <li> {} - group the characters of macro name or an indirection to an ini-file </li>
+ <li> - or ; or / - delimiters, which differentiate macros, which are not grouped with {} </li>
+ </ul>
+
+
+ <H4>Special Variables</H4>
+
+ <p>There are some integral variables available:</P>
+
+ <ul>
+ <li>SYSUSERCONFIG is mapped to osl_getConfigDir</li>
+ <li>SYSUSERHOME is mapped to osl_getHomeDir</li>
+ <li>SYSBINDIR is mapped to the executable's directory path</li>
+ <li>ORIGIN is mapped to the directory path of the ini/rc file itself</li>
+ </ul>
+
+ <p>A special bootstrap argument is supported. This argument
+ defines the name of the '.ini/rc' to use for finding bootstrap
+ arguments for executables. The name of the argument is:</p>
+
+<pre>
+ INIFILENAME
+</pre>
+
+<P>This argument can only be used on the command line:</P>
+
+<pre>
+ ./myapp -env:INIFILENAME=globalrc
+</pre>
+
+ <H2><A NAME="Application_Arguments">Application Arguments</A></H2>
+ <p> Application arguments are like bootstrap arguments, except, that
+ they are not specifiable via environment variables or ini-files. Application arguments
+ have to be given on the command line and are more like, the formerly called, command
+ line arguments.</p>
+
+ <p> The following two functions give access to application arguments: </p>
+ <DL>
+ <dd> oslProcessError SAL_CALL rtl_getAppCommandArg(sal_uInt32 nArg, rtl_uString **strCommandArg) </dd>
+ <dd> sal_uInt32 SAL_CALL rtl_getAppCommandArgCount() </dd>
+ </DL>
+
+ <p>
+ The function "rtl_getAppCommandArg" also supports macro expansion as defined
+ for bootstrap arguments. </p>
+
+ <TABLE width=100% summary="Footer">
+ <TR>
+ <TD BGCOLOR="#666699">
+ <P>
+ <FONT COLOR="#ffffff">Author:
+ <A HREF="mailto:kay.ramme@sun.com"><FONT COLOR="#ffffff">KayRamme</FONT></A>
+ ($Date: 2004/11/27 05:58:37 $)
+ <br/>
+ <I>Copyright 2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.</I>
+ </FONT>
+ </P>
+ </TD>
+ </TR>
+ </TABLE>
+
+</body>
+</HTML>
+
diff --git a/content/udk/common/man/concept/streams.html b/content/udk/common/man/concept/streams.html
new file mode 100644
index 0000000..74dc5c8
--- /dev/null
+++ b/content/udk/common/man/concept/streams.html
@@ -0,0 +1,772 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<HTML>
+<head>
+ <title>Streaming interfaces</title>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8"/>
+<style type="text/css">
+ <!--
+h1 { text-align:center; margin-top: 0.2cm; text-decoration: none; color: #ffffff; font-size: 6; margin-top: 0.2cm}
+h2 { margin-top: 0.2cm; margin-bottom=0.1cm; color: #ffffff;
+ background-color: #666699 }
+div li {margin-bottom: 0cm;}
+li {margin-bottom: 0.2cm;}
+dl {margin-bottom: 0.2cm;}
+dd {margin-bottom: 0.2cm;}
+dt {margin-bottom: 0.2cm;}
+-->
+</style>
+</head>
+<body>
+<table width=100% border=0 cellpadding=4 cellspacing=0 bgcolor="#666699"
+ summary=Header>
+ <tr>
+ <td>
+ <h1> Streaming interfaces </h1>
+ </td><td>
+ <a href="http://www.openoffice.org/"><IMG SRC="../../../images/open_office_org_logo.gif" ALT="OpenOffice.org" align=right width=109 height=54 border=0/></a>
+ </td>
+ </tr>
+</table>
+
+
+<!-- ************************ A B S T R A C T *************************************** -->
+<h2 id="abstract"> Abstract </h2>
+
+<p>This draft introduces the streaming interfaces (package
+ com.sun.star.uno.io) and gives some examples about how they can be
+ used.</p>
+
+ <p><font size=-1>
+ <u>Note</u>: In some pictures there is a ignoreable 2 in the
+ interface names (e.g. XInputStream2).</font></p>
+
+<!-- ************************ C O N T E N T *************************************** -->
+<h2 id="contents"> Contents </h2>
+<blockquote>
+<a href="#introduction">Introduction</a><br/>
+<a href="#the_interfaces">The interfaces</a><br/>
+<div>
+<ul class=compact>
+ <li>The 1st level : XInputStream/XOutputStream
+ <li>The 2nd level : XActiveDataSink/XActiveDataSource
+ <li>Chaining
+ <li>Piping
+ <li>The 3rd level : XActiveDataControl
+ <li>The 4th level : XConnectable
+ <li>Errorhandling
+</ul>
+</div>
+<p><a href="#standard_services">Standard services</a></p>
+</blockquote>
+
+<!-- ************************ I N T R O D U C T I O N *************************************** -->
+<h2 id=introduction> Introduction </h2>
+
+<DL>
+ <DT>
+ This chapter introduces some notions that you will come across
+ later in this document.</DT>
+
+ <DT>
+ A <B>datasource</B> is an object, that has some data. A <B>datasink</B>
+ is an object that gets some data. Note that no assumption is made
+ about how data is transfered, only the direction of dataflow is
+ fixed (Fig 1.). Note also, that one object can be datasource and
+ datasink at the same time, for example a filter receives data from
+ somewhere (=sink), modifies this data, and broadcasts this data again
+ (=source).</DT>
+ <DT>
+ <IMG SRC="../images/stream_source_sink.gif" NAME="Rahmen1" ALT="Rahmen1" WIDTH=298 HEIGHT=164 BORDER=0/>
+ </DT><DT>
+ Datasources and datasinks can be <B>active</B> or
+ <B>passive</B>.
+ </DT>
+ <DT>
+ 1) A <B><I>datasink</I></B> is <B><I>active</I></B>
+ when in the thread of execution the datasink calls a method of
+ datasource to get some data. In this case, the <B><I>datasource </I></B>is
+ <B><I>passive</I></B>.</DT>
+ <DT>
+ <IMG SRC="../images/stream_active_sink.gif" NAME="Rahmen2" ALT="Rahmen2" WIDTH=296 HEIGHT=165 BORDER=0/>
+ </dt><dt>
+ 2) A <B><I>datasource</I></B> is <B><I>active</I></B>
+ when in the thread of execution the datasource calls a method of
+ datasink to write some data. In this case, the <B><I>datasink</I></B>
+ is <B><I>passive</I></B>.</DT><DT>
+ <IMG SRC="../images/stream_piping.gif" NAME="Rahmen3" ALT="Datasink passive diagram" WIDTH=296 HEIGHT=159 BORDER=0 />
+ </DT><DT STYLE="margin-bottom: 0.5cm">
+ Streams offer fixed interfaces to do the data transfer.
+ At the lowest level, streams transport bytes. Data does not need to be
+ transported in one piece but can be sliced into multiple pieces. To
+ reflect the two cases above, there exist <B>inputstreams</B> and
+ <B>outputstreams</B>. Inputstreams are used in the active
+ sink-passive source scenario and outputstreams are used in the
+ active source-passive sink scenario.</DT></DL>
+
+<!-- ************************ T H E I N T E R F A C E S ******************************** -->
+<h2 id="the_interfaces"> The interfaces </h2>
+
+<DL>
+ <DT STYLE="margin-bottom: 0.5cm">The design of the streaming
+ interfaces had three major goals :</DT></DL>
+<UL>
+ <LI>
+ Easy to implement and short interface. Few interfaces to start with.
+ Extension interfaces to make the component more flexible and
+ reusable.
+ <LI>Allow easy <I>chaining</I> and
+ <I>piping</I> of streams (see below).
+ <LI>Symmetric interfaces. The input/output symmetry of the
+ problem should be reflected by the interfaces.
+</UL>
+<DL>
+ <DT>Below you can find the results of the design.
+ </DT><DT>
+ There is a kind of a four-level hierarchy indicated by the dotted lines.
+ </DT><DT STYLE="margin-bottom: 0.5cm">
+ <IMG SRC="../images/stream_interfaces.gif" NAME="Grafik1" WIDTH=632 HEIGHT=682 BORDER=0 alt="Stream interfaces"/>
+ </DT><DT STYLE="margin-bottom: 0.5cm">
+ <FONT SIZE=2><I>Fig 5. The new streaming interfaces in a 4 level
+ structure</I></FONT></DT></DL>
+
+<H4> The 1<SUP>st</SUP> level : XInputStream/XOutputStream </H4>
+
+<DL>
+ <DT>A basic streaming facility can be
+ implemented with XInputStream or XOutputStream alone.</DT><DT>
+ Example (see also the <a href="#introduction">introduction chapter</a>) :</DT>
+ <DT STYLE="margin-bottom: 0.5cm">
+ There is an object source that has some data, and an
+ object sink that wants to get some data. There are two possibilities
+ to fulfil the task :
+ </DT></DL>
+
+<UL>
+ <LI>
+ source implements an XInputStream and sink reads
+ actively from it. In this case, source is a <B><I>passive-data-source</I></B>
+ and sink is an <I><B>active-data-sink</B>.</I>
+ <LI>sink implements an XOutputStream and source
+ writes actively into it. In this case, source is an
+ <B><I>active-data-source</I></B> and sink is a <B><I>passive-data-sink.</I></B>
+</UL>
+<DL>
+ <DT STYLE="margin-bottom: 0.5cm">Sample implementation
+ ( for simplicity no error handling here ).
+ </DT></DL>
+
+<PRE>//simple scenario : 200 bytes shall be transfered from source to target
+//active sink, passive source scenario.
+class source : public XInputStream, public ....
+{
+ ...
+ // set the actual position to zero
+ source() { index = 0; }
+
+ // XinputStream.readBytes()
+ INT32 readBytes( Sequence<unsigned char> &seq , INT32 nBytes )
+ {
+ // beware eof !
+ INT32 nCopy = min( nBytes, 200-index );
+
+ // allocate memory for the requested number of bytes
+ seq.realloc( nCopy );
+
+ // put the data into the sequence
+ memcpy( seq.getArray() , &acData[index] , nCopy );
+
+ // increase actual position
+ index += nCopy;
+
+ return nCopy;
+ }
+
+ // XInputStream.skipBytes()
+ INT32 skipBytes( INT32 nBytes )
+ {
+ // beware eof !
+ INT32 nCopy = min( nBytes, 200-index );
+
+ // increase actual position
+ index += nCopy;
+
+ return nCopy;
+ }
+
+ // XInputStream.available()
+ INT32 available()
+ {
+ return 200-index;
+ }
+
+ // XInputStream.closeInput()
+ void closeInput()
+ {
+ // no special closing procedure in this simple example
+ }
+
+ ...
+private:
+ unsigned char acData[200];
+ INT32 index;
+};
+
+
+// the active datasink
+// No error or exception handling for simplicity
+class sink : public XXXXXXX, .....
+{
+ // method of interface XXXXXXX
+ void readFromStream( const Reference< XInputStream > &r )
+ {
+ Sequence<unsigned char> seq(10);
+
+ BOOL bContinue = TRUE;
+
+ // number of bytes that have been read
+ INT32 nRead;
+
+ while( bContinue ) {
+ // read from the inputstream in 10 byte steps
+ nRead = r->readBytes( seq , 10 )
+
+ // ... do something with seq
+
+ // check, if eof has been reached
+ bContinue = ( 10 == nRead );
+ }
+ // close the stream
+ r->closeInput();
+ }
+}
+
+///in main :
+{
+ Reference< XInterface > source;
+ Reference< XInterface > sink;
+
+ // instantiate source and sink through some service.
+ ....
+
+ // query the inputstream
+ Reference< XInputStream > input_stream( source , UNO_QUERY );
+
+ // query the sink
+ Reference< XXXXXXX > some_interface( sink , UNO_QUERY );
+
+ // do the reading
+ some_interface->readFromStream( input_stream );
+}
+</pre>
+
+<h4> The 2<SUP>nd</SUP> level : XActiveDataSink2/XActiveDataSource2 </h4>
+ <dl>
+ <dt style="margin-bottom: 0.5cm">To make the above sample code more
+ flexible, the sink class may
+ implement XActiveDataSink. Calling the setInputStream()-method
+ informs the sink from where to read the data. Thus the code becomes
+ more generic, (sink is only required to support the small
+ XActiveDataSink rather than Reference< XXXXXXX > ).</DT>
+ <DT style="margin-bottom: 0.5cm">
+ When to start the data transfer, depends on the implementer of
+ XActiveDataSink.
+ </DT>
+ <DT STYLE="margin-bottom: 0.5cm">
+ Here there are three possibilities.
+ </DT></DL>
+<OL>
+ <LI> In the call to XActiveDataSink.setInputStream() the whole data
+ transfer is done. This is the worst possibility, because a user may
+ not expect a set-method to behave this way.
+
+ <LI>The call to
+ XActiveDataSink.setInputStream() starts a thread that does the
+ data transfer. This is a better solution, because the call is not
+ blocking. Nevertheless the user must still be aware, that everything
+ is well prepared for transfer when the call is made.
+
+ <LI>The call to XActiveDataSink2.setInputStream() just informs
+ the object where to read from. The start of data transfer is done
+ over another method. This may be the start()-method of
+ XActiveDataContro2 (see below).
+</OL>
+
+<DL>
+ <DT>The 3<SUP>rd</SUP> solution is by far the best one, because 1) +
+ 2) are more difficult to reuse and may lead to deadlocks, etc.</DT>
+ <DT>
+ Note that everything said about XActiveDataSink also holds for
+ XActiveDataSource.</DT>
+</DL>
+
+<h3> 2.2.1 Chaining </h3>
+<DL>
+ <DT>An interesting application of the first 2 interface-levels is
+ the <B>chaining</B> concept.
+ </DT>
+ <DT>
+ Imagine you have written the XInputStream implementation OFile, that
+ offers raw data stored in a file. Then you have an arbitrary
+ application, that has implemented XActiveDataSource. After you have
+ connected both objects via setInputStream(), you have the connection
+ shown in Fig. 6a.</DT>
+ <DT>
+ <IMG SRC="../images/stream_chaining.gif" NAME="Rahmen6" ALT="Rahmen6" WIDTH=586 HEIGHT=349 BORDER=0/>
+ </DT><DT>
+ Now a file shall be read, that uses a different file format. One
+ could either modify OFile or application to do the conversion, but
+ there is a better solution. An independent service OConverter can be
+ used, it implements XActiveDataSink and XInputStream. Now the input
+ stream of OFile can be plugged into OConverter and the input stream
+ of OConverter can be plugged into application (Fig 6.b).</DT><DT>
+ Note that it is not necessary to change either application or OFile,
+ only the plugging before the start of data transfer must be adapted.
+ If desired, this may be decided at runtime.</DT>
+ <DT>
+ Note also, that you can easily insert more converters into the
+ chain.
+ </DT>
+</DL>
+
+<PRE>The following code samples show how plugging is done.
+/// Plugging for Fig 6b (without error handling)
+{
+ Reference<XInterface > application;
+ Reference<XInterface > OConverter;
+ Reference<XInterface > OFile;
+
+ // instantiate the three objects via services, put them into the above references
+ .....
+
+ // query the interfaces
+ Reference< XInputStream > aFileInputStream( OFile , UNO_QUERY );
+ Reference< XInputStream > aConverterInputStream( OConverter , UNO_QUERY );
+ Reference< XActiveDataSink > aConverterSink( OConverter , UNO_QUERY );
+ Reference< XActiveDataSink > aApplicationSink( application , UNO_QUERY );
+
+ // plug the connection
+ aConverterSink.setInputStream( aFileInputStream );
+ aApplicationSink.setInputStream( aConverterInputStream );
+
+ // start data transfer
+ ...
+}
+</PRE>
+
+ <dl>
+ <DT>
+ The following figure shows the resulting calling sequence for a
+ readBytes()-call for both cases.</DT><DT>
+ <IMG SRC="../images/stream_read.gif" NAME="Rahmen7" ALT="Rahmen7" WIDTH=356 HEIGHT=260 BORDER=0/>
+ <DT>
+ <IMG SRC="../images/stream_read_and_convert.gif" NAME="Rahmen8" ALT="Rahmen8" WIDTH=570 HEIGHT=363 BORDER=0/>
+ </DT>
+ <DT>
+ Note that the <B>order of plugging</B> may be significant if
+ data transfer is started with the setInputStream method. Again the
+ last line of the above sample code :</DT><DT STYLE="margin-bottom: 0.5cm">
+ a)
+ </DT>
+</DL>
+
+<PRE>{
+ // plug the connection
+ aConverterSink.setInputStream( aFileInputStream ); // first connect passive parts.
+ aApplicationSink.setInputStream( aConverterInputStream ); // active player is connected last,
+ // no problems can arise
+}
+
+b)
+{
+ // plug the connection
+ aApplicationSink.setInputStream( aConverterInputStream ); // application starts to read but OConverter
+ // is not connected to anything.
+ aConverterSink.setInputStream( aFileInputStream );
+}
+</PRE>
+
+<p>The problem can be avoided :</p>
+
+<OL>
+ <li> Use code sample a) instead of b) when plugging. ( Responsibility
+ is left to the user ). When b) is used, OConverter will throw an
+ exception.
+
+ <li>OConverter can be designed, so that it can cope with the problem. If
+ it is not connected to anything, but its read()-method is called, it
+ could wait in a condition up to the moment when connection is
+ established. Note that this is not an ideal solution, if the
+ connection never gets established there remains a dead thread
+ without any sign of an error. It also must be implemented again and
+ again for each converter.
+
+ <LI>Do not start the data transfer with these set-methods. Better
+ use XActiveDataControl (see below)
+</OL>
+
+<DL>
+ <DT>
+ Note : It can be quite difficult to implement a OConverter, that
+ modifies the number of bytes to read. The skipBytes(), readBytes()
+ and available()-methods must always return the requested number of
+ bytes, in such cases, converters must do at least some buffering on
+ their own. For such applications it is in general easier to
+ implement an output stream (and use pipes and threads to get the
+ desired interface, see below). However this may be too expensive in
+ some cases.</DT>
+</DL>
+
+<h3> 2.2.2 Piping </h3>
+
+<DL>
+ <DT>Motivation :</DT><DT>
+ For a lot of applications it is necessary to have more than one
+ active player in the game. Imagine you have a datasource that can
+ only write actively and a datasink that can only read actively and
+ you want to connect them. This can be done by a pipe. A pipe offers
+ an OutputStream to write to and an InputStream to read from. Thus it
+ must buffer the data that come in via XOutputStream.</DT>
+ <DT>
+ Fig. 9 shows a concrete example for a pipe. A file x is copied into
+ file y. OFileReader reads file x in certain slices. Each slice is
+ written via the output stream to OPipe. OFileWriter gets actively data
+ from OPipe and writes it directly into file y. The connection is
+ plugged with standard components (which still need to be
+ implemented), they can be used in other scenarios independent of
+ each other.</DT>
+ <DT>
+ <IMG SRC="../images/stream_piping.gif" NAME="Rahmen9" ALT="Rahmen9" BORDER=0/>
+ </DT><DT STYLE="margin-bottom: 0.5cm">
+ The following source code shows how the above connection is
+ established (for simplicity without error handling).</DT></DL>
+
+<PRE>
+{
+ Reference< XInterface > OFileWriter, OPipe, OFileReader;
+
+ // instantiate them via a standard service
+ ....
+
+ // get the interfaces
+ Reference< XActiveDataSink > sink( OFileWriter, UNO_QUERY );
+ Reference< XOutputStream > pipeOut( OPipe , UNO_QUERY );
+ Reference< XInputStream > pipeIn( OPipe , UNO_QUERY );
+ Reference< XActiveDataSource > source( OFileReader , UNO_QUERY );
+
+ // do the plugging
+ sink.setInputStream( pipeIn );
+ source.setOutputStream( pipeOut );
+ // now work with the connection ( sink and source )
+}
+</PRE>
+
+ <dl>
+ <DT>
+ Note : You can insert further filters and converters via chaining.
+ For example you can insert an instances of OConverter (above example)
+ between OFileWriter and OPipe.</DT>
+ <DT>
+ Note : A pipe can also be seen as a mechanism to transform an output
+ stream into an input stream at the costs of the buffer resources.</DT>
+ <DT>
+ Note : By exchanging OFileWriter with an object that implements
+ XActiveDataSink and XActiveDataSource, one could add a further
+ pipe. This shows the flexibility of the concept.</DT>
+ </DL>
+
+<H4> The 3<SUP>rd</SUP> level : XActiveDataControl </H4>
+
+<DL>
+ <DT>The question 'when should data transfer start ?' is not solved
+ sufficiently. One can say that as soon as the last connection has
+ been plugged, the data starts to flow. That is not acceptable for
+ some applications. An generic interface is needed, which can one use
+ to initiate the data transfer. This is the role of
+ XActiveDataControl.</DT>
+ <DT>
+ XActiveDataControl should be implemented with XActiveDataSink or
+ XActiveDataSource, thus each active player in the game should
+ implement it.</DT>
+ <DT>
+ XActiveDataControl offers a non-blocking start()-method to initiate
+ data transfer. The terminate()-method should abort the data transfer
+ before it is normally finished. Usually this should be done by
+ calling the close()-method of the connected streams. See error
+ handling for further information.</DT>
+ <DT STYLE="margin-bottom: 0.5cm">
+ <IMG SRC="../images/stream_datacontrol.gif" NAME="Rahmen10" ALT="Rahmen10" WIDTH=559 HEIGHT=229 BORDER=0/>
+ </DT></DL>
+
+<PRE>
+To startup the above sample pipe, the following code is necessary :
+{
+ Reference< XInterface > OFileWriter, OPipe, OFileReader;
+
+ // instantiate them via a standard service
+ ....
+
+ // get the interfaces for plugging
+ Reference< XActiveDataSink > sink( OFileWriter, UNO_QUERY );
+ Reference< XOutputStream > pipeOut( OPipe , UNO_QUERY );
+ Reference< XInputStream > pipeIn( OPipe , UNO_QUERY );
+ Reference< XActiveDataSource > source( OFileReader , UNO_QUERY );
+
+ // plug ( data transfer is not started )
+ sink.setInputStream( pipeIn );
+ source.setOutputStream( pipeOut );
+
+ // get the interfaces for starting
+ Reference< XActiveDataControl > controlSink( OFileWriter );
+ Reference< XActiveDataControl > controlSource( OFileReader );
+
+ // start
+ controlSink.start(); // order of starting is not important, the whole connection already exists.
+ controlSource.start(); // it may be less expensive to start sink first, because OPipe
+ // may need less resources for buffering.
+}
+</PRE>
+
+<p>XActiveDataControl also offers a listener administration.</p>
+
+<H4> The 4<SUP>th</SUP> level : XConnectable</H4>
+
+<DL>
+ <DT>The held references in Fig. 10 are unidirectional. There is no
+ generic way to get from OFileWriter to OFileReader. This maybe
+ interesting for further streaming administration services.</DT>
+ <DT>
+ Here now appears XConnectable on stage. Every class in the
+ connection should implement XConnectable. Below (Fig.11 and Fig.
+ 12) you find the extended version of the above examples.</DT><DT>
+ <IMG SRC="../images/stream_connected_chain.gif" NAME="Grafik2" WIDTH=669 HEIGHT=240 BORDER=0 alt="Stream connected chain"/><br clear=left/>
+ <FONT SIZE=2><I>Fig
+ 11. Extended example (see fig. 6b). Each element in the connection
+ implements XConnectable and connects to their neighbours. Thus it is
+ possible to reach Application from OFile. The direction of the
+ connection (successor/predecessor) is determined by the direction
+ of dataflow.</I></FONT></DT><DT>
+ <IMG SRC="../images/stream_connected_pipe.gif" NAME="Grafik6" WIDTH=559 HEIGHT=259 BORDER=0 alt="Stream connected pipe"/><br clear=left/>
+
+ <I>Fig
+ 12. Extended example (see fig 10). Now every element of the
+ connection is reachable with one arbitrary element.</I></DT>
+ <DT STYLE="margin-bottom: 0.5cm">
+ The extra plugging work should not be left to the user. In order to
+ get this working with the least effort for the user, the
+ implementation of the XActiveDataSink.setInputStream() or
+ XActiveDataSource2.setOutputStream() must be modified the following
+ way:</DT></DL>
+<PRE>
+OFileWriter::setInputStream( const Reference< XInputStream > &r )
+{
+ /// store the inputstream reference for later use
+ m_in = r;
+
+ /// does the instance provide a XDataSourceRef ?
+ Reference< XConnectable > predecessor( r , UNO_QUERY );
+ setPredecessor( predecessor );
+}
+
+application::setPredecessor( const Reference< XConnectable > &r )
+{
+ /// if the references match, nothing needs to be done
+ if( m_pred != r ) {
+ /// store the reference for later use
+ m_pred = r;
+
+ if( m_pred.is() ) {
+ /// set this instance as the sink !
+ m_pred.setSuccessor( this );
+ }
+ }
+}
+
+</PRE>
+ <dl>
+ <dt>
+ A similar implementation of for setSuccessor allows to get the
+ desired references with no extra work for the user.</DT>
+ <DT>
+ There now exists a <B>ring reference</B>, which raises a
+ deallocation-problem. This can be solved sufficiently, when in
+ close()-operations all references are explicitly deleted.</DT><DT STYLE="margin-bottom: 0.5cm">
+ OConverter::closeInput()</DT></DL>
+<PRE>{
+ /// send the close to the chained partner
+ getInputStream()->closeInput();
+
+ //.... do some tiding up, that is necessary when closing.
+
+ /// release all references
+ setPredecessor( Reference< XConnectable >() );
+ setSource( Reference< XConnectable >() );
+ setInputStream( Reference< XInputStream >() );
+}
+</PRE>
+<p>Note that any object, which does not support this XConnectable mechanism will interrupt the connection.
+
+<dl>
+<DT style="margin-bottom: 0.5cm">
+ The sense of XConnectable is maybe not very clear. Note that
+ implementing this underlying connection of elements will allow to
+ create standard services, that can help to establish and
+ administrate connections of streams. This may be an important reason
+ for using this new streaming interfaces, that's why you are strongly
+ encouraged to implement them.
+ </DT><DT STYLE="margin-bottom: 0.5cm">
+ An use case may be a video stream, where the sink wants to change
+ some settings at source, but the sink doesn't know the source. It
+ can then use XConnectable to wander to the source, where it can
+ query on a known interface.</DT></DL>
+
+<H3> 2.5 Errorhandling </H3>
+
+<DL>
+ <DT>This chapter deals with abnormal conditions that may occur when
+ using streams.</DT><DT>
+ <IMG SRC="../images/stream_connected_pipe.gif" NAME="Grafik5" WIDTH=559 HEIGHT=259 BORDER=0 alt="Stream connected pipe"/>
+ </DT><DT>
+ Let's take the <B>pipe</B> example as a basis for discussion.</DT>
+ <DT>
+ In the normal case both FileReader and FileWriter start to do their
+ job. When FileReader has read all data from the file x and has
+ written all data into the outputstream, it must call closeOutput on
+ XOutputStream. This will disconnect OPipe and OFileReader,
+ OFileReader may be deleted. When OFileWriter tries to read beyond
+ eof, it realizes that it gets less bytes than questioned. This is
+ interpreted by OFileWriter as eof sign. It then calls closeInput on
+ the XInputStream and frees its own resources. The reference between
+ OPipe and OFileWriter is removed, OFileWriter and OPipe may be
+ deleted.
+ </DT>
+ <DT STYLE="margin-bottom: 0.5cm">
+ Possible error scenarios are :</DT></DL>
+<OL>
+ <LI>
+ Error during reading file x (OFileReader). In that case OFileReader
+ closes its internal resources, broadcasts an error to all listeners
+ and calls closeOutput() on outputstream. Note that OPipe and
+ OFileWriter cannot distinguish between a normal eof-close and a
+ error close (unless they are listeners).
+
+ <LI>Error during writing file y
+ (OFileWriter). In that case, OFileWriter closes its internal
+ resources, broadcasts an error to all listeners and calls
+ closeInput() (which will disconnect OFileWriter from OPipe ) on
+ inputstream. OFileReader is still writing on OPipe's outputstream.
+ At any time after the closeInput() call, OPipe may throw an
+ IOException, if OFileReader calls a write-method. OFileReader
+ catches the exception, calls closeOutput() on the outputstream,
+ which will disconnect OPipe from OFileReader. It may also broadcast
+ an error to all listeners.
+
+ <LI>Error in OPipe (e.g. buffer full).
+ At any time after the exceptional state has occurred, OPipe will
+ throw exceptions for every read call and every write call.
+ OFileReader and OFileWriter must then call
+ closeInput()/closeOutput() and broadcast an error.
+
+ <LI>terminate()-method on OFileReader or OFileWriter is called.
+ This can be handled very similar to the above error conditions,
+ except that the terminated()-handler must be called.
+</OL>
+<DL>
+ <DT STYLE="margin-bottom: 0.5cm">
+ Note that all above errors in general occur in a multi-threaded
+ environment. Especially situations as that the terminate()-method of
+ OFileWriter gets called when another thread is in the read-Method of
+ OPipe must be handled correctly. In this case, terminate must call
+ closeInput(), OPipe must return out of the reading thread with
+ eof-signature (less bytes read than questioned) and OFileWriter must
+ call only the terminated() but not the error() handler!.</DT></DL>
+
+<!-- ************************ I N T R O D U C T I O N *************************************** -->
+<h2 id="standard_services"> Standard services </h2>
+
+<p>The following standard services have been implemented . Implementations
+can be found in udk/io/source/stm.
+The dll is <B>stm.dll</B>.
+All implementations are thread safe. However it is probably not very
+meaningful, if two threads read the same input stream at the same
+time which thread gets which data is then arbitrary.
+
+<p>Note: All streams must be explicitly closed in order to free their resources
+and release their ring references.</p>
+
+<P><B>com.sun.star.uno.io.Pipe :</B>
+implements <I>XOutputStream</I>, <I>XInputStream</I> and
+<I>XConnectable</I></p>
+<p>Basic implementation (see fig 12) to connect
+input stream and output stream. In general one thread is writing data
+into the pipe and another is reading from the pipe. The pipe does the
+necessary buffering in memory.</P>
+
+<P><B>com.sun.star.uno.io.DataInputStream
+: </B>implements <I>XDataInputStream</I>, <I>XActiveDataSink</I> and
+<I>XConnectable</I></p>
+<p>Provides the XDataInputStream functionality.
+Must be chained to another XInputStream (e.g. a pipe) to be
+meaningful.</P>
+
+<P><B>com.sun.star.uno.io.DataOutputStream</B>
+: implements <I>XDataOutputStream</I>, <I>XActiveDataSource</I> and
+<I>XConnectable</I></p>
+<p>Provides the XDataOutputStream functionality.
+Must be chained to another XOutputStream (e.g. a pipe) to be
+meaningful.</P>
+
+<P><B>com.sun.star.uno.io.MarkableInputStream
+: </B>implements <I>XMarkableStream</I>, <I>XInputStream</I>,
+<I>XActiveDataSink</I> and <I>XConnectable</I></p>
+<p>Provides the
+XMarkableStream functionality. When a mark is created, the
+implementations buffers all further read data. Must be chained to
+another inputstream to be meaningful.</P>
+
+<P><B>com.sun.star.uno.io.MarkableOutputStream
+: </B>implements <I>XMarkableStream</I>, <I>XOutputStream</I>,
+<I>XActiveDataSource</I> and <I>XConnectable</I></p>
+<p>Provides the
+XMarkableStream functionality. When a mark is created, the
+implementations buffers all further written data. The data is written
+further through the chain, when the mark is deleted. Even a flush
+will not have any effect. Must be chained to another outputstream to
+be meaningful.</P>
+
+<P><B>com.sun.star.uno.io.ObjectInputStream
+: </B>implements <I>XObjectInputStream</I>, <I>XActiveDataSink</I>
+and <I>XConnectable</I></p>
+<p>Provides XObjectInputStream functionality.
+All services of instances, that shall be read, must be registered
+with the global service manager. All services must implement
+XPersistObject. Must be chained to another XInputStream. Somewhere in
+the chain <B>must</B> exist an XMarkableStream.
+Be careful that all elements between this and XMarkableStream <B>must
+not</B> buffer data ( otherwise the markable stream becomes
+meaningless ) and one receives coincident results.</P>
+
+<P><B>com.sun.star.uno.io.ObjectOutputStream</B>
+: implements <I>XObjectOutputStream, XActiveDataSource</I> and
+<I>XConnectable</i></p>
+<p>Provides XObjectOutputStream functionality.
+All services, that shall be serialized, must implement
+<I>XPersistObject.</I> Must be chained to another XOutputStream.
+Somewhere in the chain <B>must exist </B>a XMarkableStream. Be
+careful that all elements between this and XMarkableStream <B>must
+not </B>buffer data ( otherwise the markable stream becomes
+meaningless) and one receives coincident results.</P>
+
+<table summary=footer width=100% bgcolor=#666699>
+<tr>
+<td>
+ <p><font color="#ffffff"> Author:
+ <a href="mailto:joerg.budischewski@germany.sun.com"> <font color=#ffffff>Joerg Budischewski</font></a>
+ ($Date: 2004/11/27 07:50:15 $)<br/>
+ <i>Copyright 2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA
+ 94303 USA.</i></font>
+ </p>
+</td>
+</tr>
+</table>
+</body>
+</HTML>
diff --git a/content/udk/common/man/concept/string_invest.html b/content/udk/common/man/concept/string_invest.html
new file mode 100644
index 0000000..b885b5a
--- /dev/null
+++ b/content/udk/common/man/concept/string_invest.html
@@ -0,0 +1,12 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+"http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+ <meta http-equiv="refresh" content="3; URL=http://wiki.services.openoffice.org/wiki/Uno/Binary/Analysis/String_Performance" />
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+<p class="Header">Redirecting....</p>
+
+</body>
+</html>
diff --git a/content/udk/common/man/concept/uno_contexts.html b/content/udk/common/man/concept/uno_contexts.html
new file mode 100644
index 0000000..f084592
--- /dev/null
+++ b/content/udk/common/man/concept/uno_contexts.html
@@ -0,0 +1,830 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<HTML>
+<head>
+<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1"/>
+<TITLE>
+UNO Contexts
+</TITLE>
+<style type="text/css">
+ <!--
+h1 { text-align:center; margin-top: 0.2cm; text-decoration: none; color: #ffffff; font-size: 6; margin-top: 0.2cm}
+h2 { margin-top: 0.2cm; margin-bottom=0.1cm; color: #ffffff;
+ background-color: #666699 }
+li {margin-bottom: 0.2cm;}
+dl {margin-bottom: 0.2cm;}
+dd {margin-bottom: 0.2cm;}
+dt {margin-bottom: 0.2cm;}
+-->
+</style>
+</head>
+<body>
+<TABLE WIDTH=100% BORDER=0 CELLPADDING=4 CELLSPACING=0 BGCOLOR="#666699">
+<TR><TD>
+ <h1> UNO Contexts </h1>
+ </td><td>
+ <A HREF="http://www.openoffice.org/">
+ <IMG SRC="../../../images/open_office_org_logo.gif" NAME="Grafik1" ALT="OpenOffice.org" ALIGN=right WIDTH=109 HEIGHT=54 BORDER=0 alt="OpenOffice.org"/>
+ </A>
+ </TD></TR>
+
+</TABLE>
+
+<h2> Contents </h2>
+
+ <p><a href="#abstract">Abstract</a></p>
+ <p><a href="#intro">Introduction to Contexts</a></p>
+ <p><a href="#component_context">Component Context</a>
+ <ul>
+ <li><a href="#context_interface">Context Interface</a></li>
+ <li><a href="#factory_context">Factory Context</a></li>
+ <li><a href="#instance_context">Instance Context</a></li>
+ </ul>
+ <p><a href="#current_context">Current Context</a></p>
+ <p><a href="#component_descr">Extensions to the XML Component Description</a></p>
+ <p><a href="#oneinstance">Migration path for existing OneInstance services</a></p>
+ <p><a href="#todos">Things left to do...</a></p>
+
+<h2 id="abstract">Abstract </h2>
+
+<p>This draft is about UNO contexts; what they are, how and under what condition
+ they make sense, and when you should use them. UNO contexts are generic
+ containers for storing arbitrary values that are either used by components
+ to get their deployment settings or control the runtime behavior of a
+ component.</p>
+ <p>Contexts are classified into static (component) contexts and dynamic (current)
+ contexts. A component context provides a component's deployment values;
+ a current context provides task-local values, such as values that are transferred
+ implicitly via a chain of calls excluding other tasks having access to
+ these values.</p>
+ <p>The following section, <a href="#intro"><i>Introduction</i></a>,
+ introduces the topic with an example.
+ The next two sections (<a href="#component_context"><i>Component
+ Context</i></a> and <a href="#current_context"><i>Current Context</i></a>)
+ present a definition and API proposal for the component and current context
+ as well as a migration path for the current API.</p>
+ <p>Finally, the last section proposes <a href="#component_descr"><i>Extensions to the XML Component Description</i></a>,
+
+ <a href="http://udk.openoffice.org/common/man/module_description.html">component description</a> by describing deployment properties of a component
+ implementation and invariants.
+ </p>
+
+<h2 id="intro"> Introduction </h2>
+
+ <p>A component implements a service (defined in UNO-IDL), that is, at
+ least the defined set of supported
+ interfaces of the service. The service builds up the contract
+ between component implementor and component user which is the way a component
+ can be accessed and used. In general, interfaces abstract from system
+ and implementation details to allow that a component implementation may
+ be exchanged for another. Therefore, component users should generally
+ not rely on a actually running component implementation. This is a desired
+ feature of components: handle them as isolated as possible. Changing
+ an interface or in general changing the way a component's functionality
+ is accessed is difficult, because client code has to be revisited
+ even for minor changes.
+ This is not always possible, if, for example, software has been
+ developed by 3rd party engineers. </p>
+ <p><img src="../images/context_example1.gif" align=right hspace=60 alt="context example"/> For
+ further explanations, consider the following example:
+ A DataService is providing
+ data in a generic way, abstracting from the specific sources from which it gets
+ the data. This approach is often chosen in software systems, because
+ it is a flexible way of extending to unknown data sources, thus avoiding
+ the need to touch the DataService.</p>
+ <p>Specific DataProvider components are plugged under
+ the generic DataService. The user runs the DataService giving a uniform
+ address for the data he wants to access, not knowing which specific
+ DataProvider is performing the request. The latter concerns
+ deployment aspects of actually existing data sources on the machine.</p>
+ <p>Running the example component on a big machine, you may want to switch
+ on caching of data to speed up access. Also, in keeping the set of interfaces
+ small, the service should not directly export an interface like <code>XCache</code>
+ or have interfaces polluted by caching flags in its access methods. The
+ set of interfaces and their methods should be kept minimal for extensive
+ use.</p>
+ <p>You also don't want to be implementing another set of interfaces
+ just to support caching functionality. It is even worse if the
+ DataProviders access further sub-services that should take caching into
+ account. In the latter case, every calling instance has to manage the
+ caching settings being propagated to the called instance. Eventually,
+ not all sub-services support caching functionality, but need
+ to forward the setting without knowing anything about it.</p>
+ <p>Last, you want a sensible (thus often different) caching policy being
+ deployed, if your application is being installed on a small or a big machine.
+ </p>
+ <p><b>Consequences</b></p>
+ <p>You want to parameterize a components' implementation, even if it is
+ accessed indirectly in a somehow weaker way than thru IDL interfaces.</p>
+ <p>To state clearly: Of course, it is always the best solution to
+ specify a component
+ comprehensively by IDL interfaces, but it is also common sense to keep
+ a service description as minimal (but sufficient) and generic as possible,
+ and avoid specifics of the underlying system.</p>
+ <p>This creates a conflict: In general, it is forbidden to use anything
+ out of a service's implementation that is not part of the service description.
+ So, by definition, you can only depend (and rely) on the service description.
+ On the other hand, as stated above, you may want it for convenience and
+ API design reasons. So there is no silver bullet, for the minority
+ of cases where one needs a possibility to customize a component's implementation
+ in a documented way.</p>
+ <p><b>Solution Proposal</b></p>
+ <p>A convenient (extendable) solution would be, if each component were
+ granted a set of named properties when it is raised. This is called a
+ UNO context. It provides deployment data to the component.</p>
+ <p>Upon raising further component
+ instances, the set of properties (context) is forwarded. The actually
+ affected component of a property takes it into account and behaves as
+ documented (see <a href="#component_descr">
+ extensions to the XML component description</a>). All other instances, in the
+ chain of raised components, ignore settings that are unknown to them. So
+ the modification of a property requires global knowledge about what
+ components get affected. You have to know if a specific property will
+ be taken into account, but <b>not</b> necessarily by which component
+ instance, in general, you don't know what further components are instantiated
+ when raising a specific component (this is an implementation detail).
+ The latter point requires a clear documentation scheme of a component's
+ deployment properties.
+ </p>
+ <p>The previous example states the deployment of a component, that is
+ when the component is installed for example by an application
+ installation. Enabling or disabling caching, the cache size, et cetera
+ -- these properties are basically
+ of a static nature, because the underlying system won't change during execution
+ of the application. For flexibility, there may be the need to switch it
+ on or off depending on the current system load. You may do this on a per-instance
+ basis (customizing a component instance) or per-call basis (customizing for the
+ current execution only). The latter aspect is clearly of a dynamic nature.
+ An example usage case may be a low-level socket API, extended by error handling
+ capabilities without changing the socket API.
+ </p>
+ <p>
+ To summarize the above:</p>
+ <ul>
+ <li><p>deployment properties for component implementations,</p></li>
+ <li><p>public definition and documentation of properties (this may include
+ invariants to test consistent deployment),</p></li>
+ <li><p>implicit propagation of properties when raising further components,</li>
+ <li><p>static customization: per component class (deployment) and per instance,</p></li>
+ <li><p>dynamic customization: per call.</p></li>
+ </ul>
+ <p>All of the mentioned customization of UNO components
+ is referred to as "UNO contexts". A UNO context delivers additional
+ runtime information for component execution. UNO contexts provide a set
+ of named values like a property bag. You can retrieve values by
+ their names; this is flexible for modifications without changing the
+ context interface.</p>
+ <p>There is a distinction between static and dynamic contexts: A static
+ context
+ (also referred as the "component context") may be used simultaneously
+ (e.g. by multiple threads), is immutable,
+ and is commonly given when a component is instantiated. The component
+ context is divided into a factory context that is accessible by all instances
+ of a component and provides persistent values to the component.
+ In addition, there is the specific component context given at instantiation
+ time, which was eventually customized by the caller that raised the component
+ instance.
+ In contrast, a dynamic context (also referred as the "current context")
+ is implicitly provided by a calling task (e.g. a calling thread)
+ to the component.</p>
+ <p>The previous example sketched again, modifying the DataProvider's
+ caching behavior on a per-instance basis:</p>
+ <p>
+ <img src="../images/context_example2.gif" hspace=60 alt="another context example"/>
+ </p>
+ <p>The caller prepares a context, putting the caching entry
+ "DataProvider.CacheOn = true" before raising the DataService.</p>
+ <p>A subsequently called DataProvider1 recognizes a "DataProvider.CacheOn"
+ flag. DataProvider2 ignores the caching properties, because it does not
+ support caching at all.</p>
+ <p>The caching property is defined as "optional", meaning it need not be
+ set and the affected component may choose a default behavior if it is
+ not set. Another attribute for a customization property is "mandatory",
+ stating that a property must be configured for running a component.</p>
+ <p>An automatic consistency test for a deployment involves, at least, the testing
+ of all invariants specified for properties. In general, invariants should
+ be implemented by the component that uses the involved properties.
+ Simple invariants may also be specified in the component description of
+ the implementation, e.g. <code><invariant type="min" value="128"/></code>.
+ For further details, have a look at the <a href="#component_descr">extensions
+ to the XML component description</a>.
+ </p>
+ <p>
+ In general, the following figure sketches context propagation along to several instances
+ (single factory context for all components):
+ <img src="../images/context_propagation.gif" hspace=20 alt="Context propogation" />
+
+<h2 id="component_context"> Component Context </h2>
+
+ <p><a name="context_interface"><b>Component Context Interface</b></a></p>
+ <p> The
+ <a href="http://api.openoffice.org/common/ref/com/sun/star/uno/XComponentContext.html">
+ component context interface</a> is basically an interface for getting
+ arbitrary values by their name. A value once retrieved via the context
+ interface will remain unmodified, which means, you retrieve the same
+ value by calling it a second time (immutable). Method
+ <code>getServiceManager()</code> has been added, because the service
+ manager instance is often needed by component implementations: </p>
+ <table width="100%" bgcolor="#ffffaa">
+ <tr>
+ <td>
+ <pre>
+module com { module sun { module star { module uno {
+
+interface XComponentContext : com::sun::star::uno::XInterface
+{
+ any getValueByName( [in] string Name );
+ com::sun::star::lang::XMultiComponentFactory getServiceManager();
+};
+
+}; }; }; };
+</pre>
+ </td>
+ </tr>
+ </table>
+ <p> The following enumeration shows common values of a static component
+ context, though not all properties need to be provided. If a component
+ could not run because of a missing property, it has to throw an exception,
+ for instance, <code>CannotActivateComponentException</code>. </p>
+ <ul>
+ <li><p><b>ServiceManager (<code>context property name="/singletons/com.sun.star.lang.theServiceManager"</code>)
+ : <code>type com.sun.star.lang.XMultiComponentFactory</code></b><br/>
+ A service manager to create and use further component instances. Every
+ <code>createInstance[WithContext]()</code> call will provide a distinct instance, no one-instance services
+ should be provided any longer. This is currently not possibly, because
+ of existing component implementations.</p>
+ </li>
+
+ <li><p><b>TypeDescriptionManager (<code>context property name="/singletons/com.sun.star.reflection.theTypeDescriptionManager"</code>)
+ : <code>type com.sun.star.container.XHierarchicalNameAccess</code></b><br/>
+ This singleton accesses the type library providing type information for UNO-IDL types
+ </p>
+ </li>
+
+ <li><p><b>AccessController (<code>context property name="/singletons/com.sun.star.security.theAccessController"</code>)
+ : <code>type com.sun.star.security.XAccessController</code></b><br/>
+ An access controller instance to perform permission checks.
+ This instance will use the policy singleton object to obtain user permission sets.
+ </p>
+ </li>
+
+ <li><p><b>User Access Policy (<code>context property name="/singletons/com.sun.star.security.thePolicy"</code>)
+ : <code>type com.sun.star.security.XPolicy</code></b><br/>
+ A user policy object reading from some persistent storage providing user permission sets, such as, permissions granted to a user.
+ </p>
+ </li>
+
+ <li><p><a name="singleton">Global</a> singleton objects are accessible
+ by their name which is prepended by <code>/singletons/</code>. This
+ should further on be used for IDL declared singleton services, for
+ example,</p>
+ <table width="100%" bgcolor="#ffffaa">
+ <tr>
+ <td>
+ <pre>
+module com { module sun { module star { module reflection {
+
+singleton theTypeDescriptionManager
+{
+ service TypeDescriptionManager;
+};
+
+}; }; }; };
+</pre>
+ </td>
+ </tr>
+ </table>
+ <p>declares a context entry
+ <code>/singletons/com.sun.star.reflection.theTypeDescriptionManager</code>
+ of an <code>TypeDescriptionManager</code> service object at runtime. It
+ is part of the deployment that this singleton is available and installed
+ into the initial factory context at runtime.</p>
+ <p>This service object will be raised "late" on first use and disposed
+ when the component context is closed down (i.e. is disposed). By
+ default, each new component context wrapping an existing one (i.e.
+ delegating unknown property requests to it) should add itself as event
+ listener to dispose itself when the previous one is disposed (=>
+ chaining).</p>
+ </li>
+ <li>Additional properties of any type may
+ be provided by the context.
+ Those properties should be prefixed by <code>/implementations/<em>implementation-name</em></code> or <code>/services/<em>service-name</em></code>.
+ In the latter case, they need to be documented in the service description.
+ </li>
+ </ul>
+ <p><a name="factory_context"><b>Factory Context</b></a></p>
+ <p>The factory context of a component is initialized when the system is
+ started.
+ Commonly one factory context for all components is read out of a central
+ configuration database at startup of the service manager. All persistent properties
+ have to be provided to all factories, because it is in general <b>not</b>
+ known which component will use a property.</p>
+ <p>Details about getting up the factory (deployment) context are not
+ discussed
+ here, because this involves specific knowledge of the underlying storage
+ and the way the system is initialized.
+ Common storage formats
+ for OpenOffice.org are the applicat.rdb or the OpenOffice.org
+ <a href="http://util.openoffice.org/common/configuration/concepts.html">Configuration service</a>.
+ </p>
+ <p>A common cppuhelper API to bootstrap using a registry database (e.g. the applicat.rdb)
+ is presented <a href="http://wiki.services.openoffice.org/wiki/Uno/Cpp/Tutorials/Introduction_to_Cpp_Uno#Bootstrapping_the_initial_component_context_.28factory_context.29">here</a>.
+ Java support is also implemented.
+ </p>
+ <p><a name="instance_context"><b>Instance Context</b></a> </p>
+ <p>The service manager implementation is extended by supporting the
+ <code>XMultiComponentFactory</code> interface. The factory helpers are
+ extended by supporting
+ <a href="http://api.openoffice.org/common/ref/com/sun/star/lang/XSingleComponentFactory.html"><code>XSingleComponentFactory</code></a>
+ interface, too.
+ It has to be assured that the factory implementations acknowledge a given
+ context and
+ service manager instance at runtime (thus not referencing statically, but
+ on every <code>createInstanceWithContext()</code> call).</p>
+ <p>The user is creating a component instance by calling on the
+ <a href="http://api.openoffice.org/common/ref/com/sun/star/lang/XMultiServiceFactory.html"><code>XMultiServiceFactory</code></a>
+ (old) or
+ <a href="http://api.openoffice.org/common/ref/com/sun/star/lang/XMultiComponentFactory.html"><code>XMultiComponentFactory</code></a>
+ interface:</p>
+
+ <table width="100%" bgcolor="#ffffaa">
+ <tr>
+ <td>
+ <pre>
+module com { module sun { module star { module lang {
+
+interface XMultiComponentFactory : com::sun::star::uno::XInterface
+{
+ com::sun::star::uno::XInterface createInstanceWithContext(
+ [in] string ServiceSpecifier,
+ [in] com::sun::star::uno::XComponentContext Context )
+ raises (com::sun::star::uno::Exception);
+ com::sun::star::uno::XInterface createInstanceWithArgumentsAndContext(
+ [in] string ServiceSpecifier,
+ [in] sequence< any > Arguments,
+ [in] com::sun::star::uno::XComponentContext Context )
+ raises (com::sun::star::uno::Exception);
+ sequence< string > getAvailableServiceNames();
+};
+
+interface XSingleComponentFactory : com::sun::star::uno::XInterface
+{
+ com::sun::star::uno::XInterface createInstanceWithContext(
+ [in] com::sun::star::uno::XComponentContext Context )
+ raises (com::sun::star::uno::Exception);
+ com::sun::star::uno::XInterface createInstanceWithArgumentsAndContext(
+ [in] sequence< any > Arguments,
+ [in] com::sun::star::uno::XComponentContext Context )
+ raises (com::sun::star::uno::Exception);
+};
+
+}; }; }; };
+</pre>
+ </td>
+ </tr>
+ </table>
+ <ol>
+ <li><p>The callee of <code>createInstanceWithContext()</code> will
+ prepare a context with its current one (that it is running on) as
+ described here:
+ </p>
+ <table width="100%" bgcolor="#ffffaa">
+ <tr>
+ <td>
+ <pre>
+any getValueByName( [in] string Name )
+{
+ if (new_properties.hasElement( Name ))
+ {
+ return new_properties.getElement( Name );
+ }
+ else
+ {
+ return factory_context.getValueByName( Name );
+ }
+}
+</pre>
+ </td>
+ </tr>
+ </table>
+ </li>
+ <li><p>The component factory's method <code>createInstanceWithContext()</code>
+ is called with the new context.</p>
+ </li>
+ <li><p>The component factory directly instantiates a component
+ forwarding the context to use.</p></li>
+ </ol>
+ <p><i>Backward Compatibility: </i>If the user is calling <code>XMultiServiceFactory::createInstance()</code>
+ (old), then the service manager's context is provided to <code>XSingleComponentFactory::createInstanceWithContext()</code>.</p>
+ <p>The service manager is the only instance that is used by older component implementations,
+ thus it is the only instance that knows the context to be propagated to
+ further component instances (implicitly calling old <code>XSingleServiceFactory::createInstance()</code>).
+ This is a potential problem, because the only solution for proper context
+ propagation would be to clone the service manager and install the new context;
+ although, one-instance component implementation (using static initializers)
+ will fatally hinder the propagation of the correct context.</p>
+ <p>For performance reasons, the current stoc service manager implementation does <b>not</b> clone <!-- xxx todo: will be implemented-->
+ the service manager in case of an <code>XSingleComponentFactory::createInstanceWithContext()</code> call.
+ This means that only directly launched service instances get the correct context.
+ In most cases, this should be no problem, because all up-to-date component implementations using component context
+ entries will call on <code>XSingleComponentFactory</code>, from entry-point service
+ objects to back-end service objects.
+ </p>
+<!-- <p><i><font color="#ff0000">What will be done, if a
+ context is given calling <code>createInstanceWithContext()</code> but
+ the component factory does not provide <code>XComponentFactory</code>?</font>:</i>
+ I propose throwing an exception, e.g. a <code>CannotActivateComponentException</code>,
+ because the component does not support context initialization.
+ </p>
+ -->
+
+<h2 id="current_context"> Current Context </h2>
+
+ <p>The dynamic context, also known as "Current Context", is bound
+ to the current execution task. A task denotes not only a process thread
+ of execution, but the current context of a task remains for dispatched
+ threads or inter-process invocation threads, for instance, a child
+ thread inherits its initial current context from its parent thread.</p>
+ <p>The current context can be accessed via the UNO runtime which is part of
+ the
+ <a href="../concept/uno_langbind.html#langspec">language binding specification</a>.
+ The runtime grants read access to the current context as well as installing
+ a different context for subsequent callers.
+ There is
+ <a href="http://wiki.services.openoffice.org/wiki/Uno/Cpp/Tutorials/Introduction_to_Cpp_Uno#Setting.2F_Retrieving_the_Current_Context">support for C/C++ by the <code>cppu</code> runtime</a> and the Java UNO runtime, although currently the context is not bridged.
+ The current context's interface is
+ <a href="http://api.openoffice.org/common/ref/com/sun/star/uno/XCurrentContext.html"><code>com.sun.star.uno.XCurrentContext</code></a>:
+ </p>
+ <table width="100%" bgcolor="#ffffaa">
+ <tr>
+ <td>
+ <pre>
+module com { module sun { module star { module uno {
+
+interface XCurrentContext : com::sun::star::uno::XInterface
+{
+ any getValueByName( [in] string Name );
+};
+
+}; }; }; };
+</pre>
+ </td>
+ </tr>
+ </table>
+
+ <p>It is always recommended to use an interface method to pass parameters,
+ due to explicit passing and type safety of parameters (caller's and
+ callee's contract). Though there are very few sensible cases for a current
+ context, common properties of the context are:</p>
+ <ul>
+ <li><p><b>access control restriction ("access-control.restriction") :
+ <code>type com.sun.star.security.XAccessControlContext</code></b></p>
+ <p>This property provides a task-local access control restriction
+ taken into account during permission checks. For details, have a look
+ at <a href="uno_security.html#dynamic_restrictions">the dynamic
+ restrictions</a> section of the security document.</p>
+ </li>
+ <li><p><b>access control user credentials ("access-control.user-credentials.*")</b></p>
+ <p>These properties relate to the calling user, e.g.
+ <code>access-control.user-credentials.id</code>. For details, have a
+ look at <a href="uno_security.html#dynamic_restrictions">the dynamic
+ restrictions</a> section of the security document.</p>
+ </li>
+ <li><p>arbitrary values for higher stack levels which occur in an
+ "optional" manner (could be described as "nice to have if set at the
+ current context") like callback/ error handlers.</p>
+ </li>
+ </ul>
+ <p>The current context interface reference must not be shared with other
+ threads.
+ In general, you should also take care to not share values you got from the
+ current context with other threads.</p>
+ <p>When calling across process boundaries, there is a question of what
+ happens to
+ the dynamic context. Of course, remote transparency is a wishful feature.
+ On the other hand, remote access on the context has to be optimized for
+ performance.</p>
+
+<!-- <i><font color="#ff0000">Open</font>:</i> Security and inter process
+ calls?<br/>
+ I propose that security relevant properties like the AccessController or
+ the authenticated Subject are not
+ transmitted, because this leads to a potential security hole (refer to
+ <a href="uno_security.html#remote">security draft</a>).<br/>
+ A process for handling this via remote may be establishing a lasting authentication
+ (over multiple calls) for a user. A previous authentication process (including
+ password dialogs, etc.) will establish a ticket on both sides (aka secure
+ association). This ticket builds up the subject. When transferring via remote,
+ only the ticket is transferred, then any authorization has to be performed
+ on the (locally authenticated) user's behalf. <br/>
+-->
+
+<h2 id="component_descr"> Extensions to the XML Component Description </h2>
+
+<p>In this section, I propose extensions to the current <a href="http://udk.openoffice.org/common/man/module_description.html">XML
+ component description</a> describing deployment properties of a component
+ implementation and invariants.
+ Invariants allow testing of a specific deployment, that is, if the specific values
+ make sense.
+ All elements appear as sub element of <code>component-description</code> which, now, may
+ also contain a <code>component-properties</code> element:</p>
+
+ <table width="100%" bgcolor="#ffffaa">
+ <tr>
+ <td>
+ <pre>
+<!ELEMENT component-description
+ (author,name,description,loader-name,supported-service+,
+ <b>component-properties?</b>,(%component-description-optional;)*)>
+
+<!ELEMENT component-properties property*>
+<!ELEMENT property description? invariant*>
+<!ATTLIST property name CDATA #REQUIRED
+ optional (true|false) #IMPLIED
+ value-type (boolean|string|number) #IMPLIED
+ default-value CDATA #IMPLIED>
+
+<!ELEMENT invariant EMPTY>
+<!ATTLIST invariant type (valid|invalid|min|max) #REQUIRED
+ value CDATA #IMPLIED>
+</pre>
+ </td>
+ </tr>
+ </table>
+
+ <p>Properties are described by their <code>name</code>,
+ <code>value-type</code>, <code>optional</code> attributes, and a number
+ of optional <code>invariant</code>s. The <code>name</code> denotes the
+ property's name as it will appear in contexts. The <code>optional</code>
+ attribute denotes whether the property can optionally
+ be set in a deployment or is mandatory (i.e. if not set, the component
+ implementation
+ cannot run). An optional <code>default-value</code> can also be set.
+ Invariants follow up as sub elements
+ to check whether a given property value makes sense. The invariants given
+ <code>value</code>
+ must always be convertible to the property's <code>value-type</code>.</p>
+ <p>Current invariant <code>type</code>s have been chosen for the
+ following strings:</p>
+ <ul>
+ <li><code>valid</code> -- denotes a valid value of the property overriding all other invariants</li>
+ <li><code>invalid</code> -- denotes an invalid value of the property overriding all other invariants except the
+ <code>valid</code> invariant</li>
+ <li><code>min</code> -- denotes a lower boundary for a property number value</li>
+ <li><code>max</code> -- denotes a upper boundary for a property number value</li>
+ </ul>
+
+ <p>Example:</p>
+ <table width="100%" bgcolor="#ffffaa">
+ <tr>
+ <td>
+ <pre>
+...
+<component-properties>
+ <property name="DataProvider1.CacheOn" value-type="boolean"/>
+ <property name="DataProvider1.CacheSize" value-type="number" default-value="256">
+ <invariant type="min" value="128"/>
+ <invariant type="max" value="512"/>
+ <description>
+ Property CacheOn controls whether caching of data should be performed.
+ Property CacheSize controls the size of the cache. The CacheSize is limited to a range
+ between 128 and 512.
+ </description>
+ </property>
+</component-properties>
+...
+</pre>
+ </td>
+ </tr>
+ </table>
+
+ <p>
+ <i><font color="#ff0000">Attention: Proposal only!</font></i>
+ The previous component description extensions
+ are yet to be discussed and extended -- and implemented --
+ with respect to further tools performing tests.
+ </p>
+
+<h2 id="oneinstance"> Migration path for existing OneInstance services </h2>
+
+<p>Formerly, a service decided to be a one instance service by choosing the appropriate factory
+( in general cppu::createOneInstanceFactory() ). When the service is first instantiated,
+the factory keeps a hard reference to the service. All subsequent createInstance()-calls
+return the same object. When the servicemanager got disposed, it disposed all factories,
+which released the reference.
+
+<p> The former OneInstance services can be separated into the following categories :
+
+<ol>
+<li><p>Services that have state or instantiate other services.</p></li>
+<li><p>Services that don't have state and that don't instantiate further
+ services.
+ These services are OneInstance for optimization reasons
+ ( it would be a waste of heap to have multiple instances).
+ A classical example is the TypeConverter services, which offers simple
+ conversion functions.
+ </p></li>
+</ol>
+
+Each group must be treated differently when moving to the context concept.
+
+<ol>
+<li><p>These are
+<a href="#singleton">singletons</a>.
+These objects should be placed into the context.
+You use a normal factory, so that it is possible to instantiate multiple instances.
+You add a singleton entry to the idl-file. All clients, that previously accessed the object
+via the servicemanager, must switch to accessing it via a context. This is a required change.
+</p>
+<p> If there is not time to make the changes immediately, then stick to the OneInstance
+service, as it is currently, and schedule a task force for it.
+</p>
+
+<p> There may be exceptions, for instance, the javavm service can only be started once per process and
+ it must not die (because the javavm can not be released once it has been started).
+ Such conditions should be handled by the component internally, that is, the javavm-service
+ will hold its self or it will keep a list of the contexts it is used in, and adds itself as
+ disposing listeners. These exceptions should be really rare !
+ </p>
+
+<p> Another possibility may be to make it a normal service.</p>
+
+<li><p>These services can be reused over all contexts, so a single instance per
+process is
+desired. These services should use a normal factory, but within the dll-local createInstance()
+function, they keep a static weak reference on the object. For every createInstance()-call,
+it first checks the weak reference. Otherwise, it instantiates the implementation and assigns
+it to the weak reference.
+</p></li>
+</ol>
+
+<h2 id="registries"> Registry considerations for context-information </h2>
+<p>The following deployment issues arise when introducing contexts:</p>
+
+<ol>
+<li><p>There is need for a place to store the singleton information (i.e. the
+ name of the service
+ to be instantiated when a singleton gets accessed the first time).</p></li>
+<li><p>There is need for a place to store implementation-dependent context settings.</p></li>
+</ol>
+
+<h4>Singleton</h4>
+<p>A singleton gets a service-name assigned in an idl-file (which means at
+specification time). For example, the com.sun.star.theBridgeFactory-singleton
+is assigned to the com.sun.star.bridge.BridgeFactory service and can be
+instantiated at runtime using this name.</p>
+<p>But the specification in idl is only minimal, the singleton instance must,
+<b>at least</b>, support this service. Take a look at the service-manager;
+something that we call a service-manager must at least support the
+
+<a href="http://api.openoffice.org/common/ref/com/sun/star/lang/MulitServiceFactory.html">
+com.sun.star.lang.MultiServiceFactory</a>
+
+service, so this is specified in IDL. However, in OpenOffice.org, we need a
+<a href="http://api.openoffice.org/common/ref/com/sun/star/lang/RegistryServiceFactory.html">
+com.sun.star.lang.RegistryServiceFactory</a>
+service, which additionally supports the MultiServiceFactory.
+This information can't be retrieved from IDL anymore, it must be defined at
+deployment time.</p>
+
+<p>
+The initial routine, that creates the context, must be able to access the
+singleton-information. This information should be provided in an .rdb-file
+(the only persistent storage we have on the UDK-level). The following kinds of
+information is currently stored in an .rdb-file:</p>
+
+<ol>
+<li><p>Types (needed by the typeprovider),</p></li>
+<li><p>Service registrations (needed by the RegistryServiceManager),</li>
+<li><p>Singleton information (needed by the initial routine that creates the
+context).</p></li>
+</ol>
+
+<p>I think a good strategy is to have one .rdb-file for each category. This
+avoids unnecessary nesting of registries and gives the most flexibility when
+multiple processes shall share registries (though it always needs to be taken
+into account that a registry can only be opened with write access, when no
+other process have read or write access to the same registry). To reflect this,
+we should introduce the following bootstrap-variables :</p>
+
+<ul>
+<li><p>UNO_TYPESRDB (contains a list of registry-names that contain type information
+ [read-only-access])</p></li>
+<li><p>UNO_SERVICESRDB (contains a list of registry-names that contain the registered services
+ [read-only-access])</p></li>
+<li><p>UNO_CONTEXTRDB (contains a list of registry-names that contain the singleton-information
+ [read-only-access])</p></li>
+<li><p>UNO_SERVICESRDB_RW (contains exactly one registry name where service information
+ can be written)</p></li>
+</ul>
+
+Note that you still can have one registry, that holds all information (types,services, and contexts).
+This registry would get opened three times, which bears no problem as long as it is
+opened for read only.
+
+<h4>Additional context settings</h4>
+<p>The context contains (besides singletons) component specific values. This
+information
+must be available when the context is created, so, it seems a good idea to insert this information
+into the above suggested .rdb-file.</p>
+
+<p> The registry does not offer to store all possible UNO-types, since it must store the value as
+a byte-sequence ( with some routines such as any2Sequence() and sequence2Any() in cppu).</p>
+
+<p> There needs to be a command line-tool, that inserts values into a rdb.</p>
+
+<h4>Integration into the build process</h4>
+<p>There is no comprehensive solution-suggestion currently, so here are listed
+some thoughts.</p>
+
+<ul>
+<li><p>The singleton-information specified in IDL must be available outside
+ udkapi/offapi project. This should be delivered as its own .rdb-file
+ (maybe udk_singleton.rdb).</p></li>
+<li><p>If we come to the conclusion
+ that the creation of the service-manager will probably always be hardcoded, it should be
+ sufficient, currently, for most tools not to have a context .rdb-file.</p></li>
+<li><p>How do we get a context.rdb for an application? The knowledge on what
+ should be in the
+ context.rdb is distributed.</p>
+ <ul>
+ <li> The component developer wants to give some sensible defaults to context values.
+ <li> At the time the setup for a certain application is built, one wants to insert
+ only those context values that could be needed in the deployed application.
+ Here it will be very difficult to avoid redundancies for multiple applications.
+ <li> The setup wants to install only context values for installed components and it
+ wants to omit other ones.
+ <li> The user/deployer wants to modify or add context values.
+ </ul>
+
+</ul>
+
+<h4>Registry limitations</h4>
+<p>A lot of deployment problems arise from storing information into an
+.rdb-file. We definitely need a database in core UNO as soon as possible.
+It is planned to use the configuration services for this and to move component
+registration into it. This will ease getting overviews about components,
+implementations, properties, singletons, location, et cetera.
+Registry database files (rdb) are only used for type access.</p>
+<p>The coming structure of the configuration (which is read-only accessible via
+the component context) will look like this:</p>
+
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+/singletons/theFoobar/
+ service = Foobar
+ [arguments = { ... }]
+...
+
+/services/Foobar/
+ available-implementations = { FbImpl[, ...] }
+ uses-implementation = FbImpl
+ [<arbitrary conceptional properties>]
+...
+
+/implementations/FbImpl/
+ supports-services = { Foobar[, ...] }
+ url = libfoobar.so
+ activator = com.sun.star.loader.SharedLibrary
+ [<arbitrary properties>]
+...
+</pre></td></tr></table>
+<p>
+<em>
+(last two sections co-edited by <a href="mailto:joerg.budischewski@sun.com">Joerg
+Budischewski</a>.)</em></p>
+
+<h2 id="todos">Things left to do... </h2>
+
+<p>The following things are left to do:</p>
+
+<ul>
+<li><p><b>[high priority]: </b>
+There is currently no persistent storage for component context values,
+singleton object specifications, services, and implementations. This includes
+switching service registration to this storage format.</p>
+<p>We have to use the configuration services as soon as possible, that is,
+bring configuration into UDK.</p>
+</li>
+<li><p><b>[mid priority]: </b>
+Supporting <code>XMultiServiceFactory</code> the service manager has to be
+revisited. The service manager has to clone itself (changes
+<code>DefaultContext</code> property) when a
+<code>createInstanceWithContext</code> changes the context of the component to
+be raised.</p>
+</li>
+<li><p><b>[low priority]: </b>
+The current context is not transferred via the URP-UNO interprocess bridge.
+This has to be fixed with no lack of performance.</p>
+</li>
+</ul>
+<table width=100% summary="Footer">
+<tr>
+<td bgcolor="#666699">
+ <p><font color="#ffffff"> Author: <a href="mailto:Daniel.Boelzle@sun.com">
+<font color="#ffffff">Daniel Bölzle</font></a><br/>
+ <i>Copyright 2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.</i></font
+</p>
+</td>
+</tr>
+</table>
+</body>
+</html>
diff --git a/content/udk/common/man/concept/uno_corba.html b/content/udk/common/man/concept/uno_corba.html
new file mode 100644
index 0000000..6cd9f85
--- /dev/null
+++ b/content/udk/common/man/concept/uno_corba.html
@@ -0,0 +1,1014 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html>
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
+ <meta name="Author" content="Gast"/>
+ <title>The CORBA-UNO-Bridge</title>
+<style type="text/css">
+ <!--
+h1 { text-align:center; margin-top: 0.2cm; text-decoration: none; color: #ffffff; font-size: 6; margin-top: 0.2cm}
+h2 { margin-top: 0.2cm; margin-bottom=0.1cm; color: #ffffff;
+ background-color: #666699 }
+li {margin-bottom: 0.2cm;}
+dl {margin-bottom: 0.2cm;}
+dd {margin-bottom: 0.2cm;}
+dt {margin-bottom: 0.2cm;}
+-->
+</style>
+</head>
+<body>
+<table WIDTH="100%" BGCOLOR="#666699" summary="header">
+<tr> <td>
+<h1> The CORBA-UNO bridge </h1>
+</td><td>
+<a href="http://www.openoffice.org/">
+<img SRC="../../../images/open_office_org_logo.gif" NAME="Grafik1" ALT="OpenOffice.org" BORDER=0 height=54 width=114 align=right/>
+</a>
+</td</tr></table>
+
+<h2>Integrating into the GNOME desktop</h2>
+<blockquote>
+<a href="#introduction">Introduction</a><br/>
+- <a href="#design_concepts">Design concepts</a><br/>
+- <a href="#corba_access">Accessing UNO processes from CORBA and vice versa</a> <br/>
+- <a href="#oneway">Oneway calls</a><br/>
+- <a href="#object_lifetime">Object lifetime</a><br/>
+- <a href="#thread_identity">Thread identity</a><br/>
+- <a href="#object_identity">Object identity</a><br/>
+- <a href="#unknown_xinterface_mapping">Mapping of XInterface and GNOME::Unknown</a><br/>
+- <a href="#multiple_inheritance">Multiple inheritance</a><br/>
+- <a href="#type_information">Type information</a><br/>
+
+<a href="#implementation_concepts">Implementation concepts</a><br/>
+- <a href="#object_identifier">Object identifier</a><br/>
+- <a href="#corba_bridge_service">Corba bridge service</a><br/>
+- <a href="#connection_management">Connection management</a><br/>
+- <a href="#iiop_version">IIOP versions</a><br/>
+- <a href="#deployment_problem">Deployment for the GNOME orbit</a>
+</blockquote>
+
+
+<h2 id="introduction"> Introduction </h2>
+
+<!-- ************************ I N T R O D U C T I O N ************************* -->
+<p>OpenOffice.org is a fully featured office productivity suite available for
+the most popular platforms. One aim of OpenOffice.org is to seamlessly
+integrate into each platform's most popular desktops.</p>
+
+<p>
+One major desktop on Linux and Solaris is developed by the open source GNOME project.
+The component model of the GNOME desktop is BONOBO, which is built on top of
+ORBIT, an open source CORBA ORB (Object Request Broker).
+</p>
+
+<p>
+To be able to communicate with the GNOME desktop, we want to develop a CORBA-UNO bridge
+using IIOP (<em>Internet inter orb protocol</em>).
+
+<h4> Goals for the bridge </h4>
+The <strong>main goal</strong> is to get a CORBA-bridge that supports all features
+necessary to communicate with
+the GNOME desktop. This would e.g. allow to script OpenOffice.org from a GNOME scripting language.
+As a <strong>secondary goal</strong> an arbitrary CORBA-ORB should be able to directly access
+OpenOffice.org using the same bridge (for example on windows). This would allow to integrate
+OpenOffice.org seamlessly into any CORBA environment.
+
+<p> However, bridging UNO and CORBA is a non trivial task, as both component
+models
+are based on <a href="../comparison_uno_corba.html">different fundamental concepts</a>.
+This document should provide concepts about how to cope with most of these
+fundamental differences. It is supposed to grow within the next weeks as
+documentation either during and after development of the bridge. It should be a kind of an
+<em>open document</em>, as that important points brought up by the community will be
+inserted here.
+</p>
+
+<h4>What exactly can be done with a CORBA-UNO bridge?</h4>
+
+<p>
+An UNO-CORBA bridge allows to e.g. call methods at an UNO object (let's say a writer document)
+from the BONOBO object model. The caller does not need to know he is calling an UNO object,
+the only thing he does is invoking a method on a CORBA interface. It is not needed for the
+caller to have any UNO libraries in process nor is it needed for the callee to have any
+orbit libraries in process.
+</p>
+
+<p>
+The other way round, the bridge allows an UNO programmer to call CORBA objects from UNO. The
+UNO programmer does not have to have any special CORBA knowledge, he simply calls on
+UNO interfaces.
+</p>
+
+<p> To support callback interfaces, it should be possible to implement CORBA-interfaces in
+UNO and vice versa.
+
+<h2 id="design_concepts"> Design concepts </h2>
+<!-- ************************ C O N C E P T S ************************* -->
+
+<h4><a name="corba_access">Accessing UNO processes from CORBA and vice versa</a></h4>
+
+<p>The main problem of accessing an object in a different process is that you
+ need the IOR (Interoperable Object Reference) of this object in the other
+ process. The most common way is to have a daemon like process (typically a
+ namingservice or a implementation repository) that administrates IORs.
+ Every CORBA application can access this daemon to retrieve an IOR of the
+ desired object.</p>
+
+<p>The root IOR of this daemon process must somehow be brought to every single
+ application. How this is done, is orb dependent (possible solutions are a
+ certain file on the filesystem, configuration files, environment variables,
+ command line parameters, etc).</p>
+
+<p>The mechanism how to access this IOR should be made abstract to allow to
+ implement a different mechanism for different orbs. A simple interface as
+ following one should be sufficient.</p>
+
+<table BORDER=0 CELLSPACING=0 CELLPADDING=4 WIDTH="100%" >
+<tr>
+<td COLSPAN="3" WIDTH="100%" BGCOLOR="#FFFFC0">
+<pre>
+ interface XRootIORProvider
+ {
+ /** tries to locate a corba root object using a specified method.
+
+ Note : In general, no CORBA bridge needs to be instantiated.
+ This IOR can be retrieved by some other mechanism.
+
+ @param howToFindObject
+ format: kind of service to find, comma separated attribute
+ list e.g. "GnomeResolverFromX,display=jbu-11096:1" or
+ similar.
+
+ @return stringified IOR, if a namingservice could be found,
+ otherwise an empty string.
+ */
+ string findRootIOR( string howToFindObject );
+ };
+</pre>
+</td>
+</tr>
+</table>
+<p>returned stringified IOR can later be used to create an UNO interface
+ reference to the object. Therefor will exist an CORBA bridge interface with
+ a method</p>
+
+<table BORDER=0 CELLSPACING=0 CELLPADDING=4 WIDTH="100%" >
+<tr>
+<td COLSPAN="3" WIDTH="100%" BGCOLOR="#FFFFC0">
+<pre>
+ interface XCorbaBridge
+ {
+ [...]
+ Any resolveByStringifiedIOR( string sIOR );
+ [...]
+ };
+</pre>
+</td>
+</tr>
+</table>
+<p>The returned Any contains an UNO interface reference. This can be used to
+ directly make calls.</p>
+
+ <ul>
+ <li><p>The gnome case (ORBIT)</p>
+ <p>Up to version 1.3, GNOME uses the gnorba framework. From version 1.4 (yet to come)
+ on, the oaf (object activation framework) is used. However, as this bridge is
+ also in a early development cycle, we will focus on the more powerful oaf-framework.
+
+ <p> Oaf is a mix of an implementation repository and the CORBA trading service.
+ Certain services can be advertised using properties (name-value pairs). Services
+ can be accessed by doing queries on properties. Accessing a service can either
+ result in starting a new process or simply returning the object reference
+ of an existing instance. Services can either be described within ini-files
+ or can be inserted at runtime (e.g. when a service starts up, it inserts itself
+ in the oaf).
+
+ <p>
+ The suggested way to use the oaf is to link against the oaf C-library and use
+ C-API functions. However the oaf offers most of its functionality via
+ idl-interfaces (e.g. in process shared library services can not be instantiated
+ via the idl-interface).
+
+ <p>
+ IMHO the best way to access oaf would be to implement an RootIORProvider service,
+ that implements the XRootIORProvider interface. The service may be started in
+ a separate process, if needed.
+ The implementation is linked linked against liboaf.so and uses the C-API to retrieve
+ the stringified IOR of the root object. The original process then instantiates
+ a CORBA bridge and tries to access it using the resolveByStringifiedIOR() method (without
+ using the interface intermediate process anymore).
+
+ <p> The service may later become simpler, if the IOR can be retrieved via a command
+ line tool or a environment variable.
+
+ <li> other CORBA orbs
+ [...]
+ </ul>
+ <p>
+ So far the problem, how OpenOffice.org can access CORBA services, is solved. But what is
+ the other way round? How can we get the OpenOffice.org servicemanager into the oaf? There
+ are multiple possible solutions.
+
+ </p>
+ <ol>
+ <li><p>Insert the UNO servicemanager IOR into oaf at Office startup.
+ This works fine as long as the office is running.
+ </p></li>
+
+ <li><p>
+ Add oafinfo-files to the oaf, so that the oaf itself can start the office, if
+ needed. The office must then behave like an arbitrary GNOME service, interpret
+ command-line parameters and use the oaf-library to do some non-corba-communication
+ with the oaf. It still needs to be investigated, if this has any problems.
+ </p></li>
+
+ <li><p>
+ (and in my eyes the CORBA way to do it) Have our own UNO daemon,
+ that itself works as implementation repository for UNO services (such as the office).
+ The office servicemanager is configured in the oaf simply by a persistent
+ stringified IOR, but uses the host/port entries of the UNO daemon. When someone
+ tries to make a call on the object, the UNO daemon starts up the office
+ and replies a LOCATION_FORWARD iiop-message with the appropriate host/port entries. To allow
+ this , ORBIT must support LOCATION_FORWARD messages (does it?).
+ </p></li>
+
+ <li><p>
+ Have a UNO daemon, that runs continuously. It implements
+ the oaf OAF::ObjectDirectory interface and inserts it into the running oaf.
+ It starts the office on demand using the office-specific command line parameters.
+ </p></li>
+ </ol>
+
+ <p>
+ Which solution will be used is not yet determined.
+
+<h4><a name="oneway">Oneway calls</a></h4>
+<p>
+CORBA does not guarantee the sequence of calls for oneways. However,
+a lot of UNO interfaces and implementations rely on that (think of the sequence
+<code> acquire(),acquire(),release()</code> gets mixed up to
+<code> acquire(),release(),acquire()</code>, this would be fatal).
+So I think, it is inevitable to
+export all UNO-oneway-methods as synchronous to CORBA.
+
+<p> Oneway with CORBA interfaces however should be supported, as there it must have been
+decided during design, that the series of calls is not important.
+
+<p> Is a special solution for
+ GNOME possible (maybe the implementation guarantees the sequence of calls)?
+
+
+<h4><a name="object_lifetime">Object lifetime</a></h4>
+<p>
+Several use cases must be taken into account when talking about object lifetime.
+</p>
+
+<table align=center border=5>
+<tr>
+<td align=center >
+use case
+</td>
+<th colspan=2 align=center>
+object used by
+</th>
+<th colspan=2 align=center>
+object implemented in
+</th>
+<th colspan=2 align=center>
+interface originally defined in
+</th>
+</tr>
+
+<tr>
+<td align=center>
+#
+</td>
+<td align=center>
+CORBA
+</td>
+<td align=center>
+UNO
+</td>
+<td align=center>
+CORBA
+</td>
+<td align=center>
+UNO
+</td>
+<td align=center>
+CORBA
+</td>
+<td align=center>
+UNO
+</td>
+</tr>
+
+<tr>
+<td align=center>1.</td>
+<td></td>
+<td align=center>x</td>
+<td align=center>x</td>
+<td></td>
+<td align=center>x</td>
+<td></td>
+</tr>
+
+<tr>
+<td align=center>2.</td>
+<td></td>
+<td align=center>x</td>
+<td align=center>x</td>
+<td></td>
+<td></td>
+<td align=center>x</td>
+</tr>
+
+<tr>
+<td align=center>3.</td>
+<td align=center>x</td>
+<td></td>
+<td></td>
+<td align=center>x</td>
+<td align=center>x</td>
+<td></td>
+</tr>
+
+<tr>
+<td align=center>4.</td>
+<td align=center>x</td>
+<td></td>
+<td></td>
+<td align=center>x</td>
+<td></td>
+<td align=center>x</td>
+</tr>
+
+</table>
+<ol>
+<li> CORBA object implementing an CORBA-interface used from UNO <br/>
+The interface-definition
+is imported from CORBA to be accessible for the UNO runtime. The interface is flagged as
+being a CORBA interface. For the UNO runtime, the interface is derived from
+<code>XInterface</code>.
+
+<p>
+The UNO-CORBA bridge must create a proxy within the UNO process, it must implement
+<code>acquire()</code>, <code>release()</code> and <code>queryInterface()</code>. As the
+interface does not support a queryInterface method, it must be dummy-implemented, so that it
+supports a query for the interface and all its superclasses.
+
+<p> The lifetime of the proxy bears no problem, it is simply refcounted. If the refcount drops
+to zero, the proxy dies silently, no message is transported to the original object.
+
+<li> CORBA object implementing a UNO-interface used from UNO <br/>
+The UNO interface-definition must be imported into the CORBA typelibrary and stub/proxy-code
+must be generated for the CORBA-process.
+The object must implement itself <code>acquire()</code>, <code>release()</code>
+and <code>queryInterface()</code> and maybe <code>getCorbaID()</code>
+(see <a href="#object_identity">below</a>).
+
+<p> Here the lifetime problem becomes a little difficult. Let us first have a look at
+lifetime handling in a UNO-UNO interprocess-bridge.</p>
+<img src="../images/passing_interface_reference_uno_uno.jpg" alt="Uno interface" />
+
+<p>
+The <code>pass()</code> call shall pass an interface reference as its first argument. The
+UNO-UNO bridge acquires the object on caller side, the bridge on callee side knows, that
+it gets an acquired interface.
+
+<p>
+This cannot be done with a general CORBA orb, because the orb runtime doesn't know,
+that it should call acquire implicitly. How can this be solved? In general,
+the callee must acquire the interface, when it wants to keep it.
+The UNO-CORBA bridge would acquire it in advance and release it again when
+the newly created proxy is destroyed. Thus the UNO-developer wouldn't need to do
+anything by hand.
+
+<p>
+<img src="../images/passing_interface_reference_corba_uno.jpg" alt="Corba uno interface"/>
+<p>
+This does NOT WORK FOR ONEWAY CALLS. This technique
+may also be inefficient, because every mapped interface requires a (maybe synchronous)
+<code>acquire()</code> call. However, as GNOME does refcounting this way, the UNO-CORBA
+bridge will also do it this way thus ignoring the problem.
+
+<p>
+<b> Acquire in advance</b><br/>
+Another possibility would be to make the CORBA developer responsible for this, if
+he passes a object-reference, he must call <code>acquire</code> in advance. This is
+very error prone (think about any, structs and sequences, that all would need to be
+parsed for object references), however this is the only way how oneway requests
+can pass object references. This could be introduced only for oneway calls, but as
+in general it cannot be seen from the method signature, whether a call is oneway or
+synchronous, this would be very confusing.
+<p>
+<img src="../images/passing_interface_reference_acquire_in_advance.jpg" alt="reference interface"/>
+
+<p>
+Another solution would be to simply ignore <code>acquire()</code> and <code>release()</code>,
+but how shall the CORBA side then get to know, when an instance can be discarded, as the
+OpenOffice.org API is not designed for telling the objects something like this?
+
+<li> UNO object implementing a CORBA-interface used from CORBA <br/>
+The CORBA-interface is derived from <code>XInterface</code> in the UNO process. So for the
+object itself, the lifetime must be controlled via <code>acquire()</code> and
+<code>release()</code> calls.
+
+<p>
+The problem is, that when the UNO-object is once mapped out to a CORBA process, the
+UNO-CORBA-bridge must hold a reference to the object and does not know, when to release it.
+(The CORBA developer does not see the <code>acquire()</code> and <code>release()</code>
+methods).
+
+<p>
+Often, CORBA interfaces are somehow designed to control lifetime of objects. For example,
+an object has an explicit <code>destroy()</code> method, on which the documentation states
+that the instance is destroyed and the object becomes unreachable. However the bridge
+can't read documentation ( :o) ), so there must be mechanism, that the implementation
+can tell the bridge, that it does not need to be held anymore.
+
+<p> As the implementation naturally does not know the bridge instance, there
+should be implemented
+a broadcast/listener mechanism to broadcast this message to all CORBA bridge instances.
+There could be a singleton service, that knows all CORBA bridges (maybe a factory,
+that creates all CORBA bridges.)</p>
+
+<table BORDER=0 CELLSPACING=0 CELLPADDING=4 WIDTH="100%" >
+<tr>
+<td COLSPAN="3" WIDTH="100%" BGCOLOR="#FFFFC0">
+<pre>
+interface XCorbaBridgeFactory : XInterface
+{
+ XCorbaBridge createBridge( ... );
+
+ void fireDisposeObject( [in] XInterface disposedObject );
+}
+</pre>
+</td>
+</tr>
+</table>
+<br/>
+<li> UNO object implementing a UNO interface used from CORBA
+ Here the CORBA developer sees the <code>acquire()</code>, <code>release()</code>,
+ <code>queryInterface()</code> and <code>getCorbaID()</code> method. Because the
+ CORBA runtime does not support <code>acquire()</code> directly, the CORBA developer
+ must call <code>acquire()</code> and <code>release()</code> by hand.
+
+ <p>
+ Interface references returned by a method (as return value or out-parameter) are
+ supposed to be acquired, thus if the references must be
+ released by the CORBA programmer, if not needed anymore.
+ This means, that a CORBA programmer who implements
+ a UNO-interface methods, that returns an interface reference (via return value or
+ out-parameter) must acquire the interface beforehand.
+
+
+</ol>
+
+<h4><a name="thread_identity">Thread identity</a></h4>
+ UNO interprocess bridges preserve thread identity, that means when process A calls
+ process B and in the same request process B calls again process A, the same thread
+ waiting in process A will take over the new request. This ensures that thread
+ local resources (locked mutexes, thread local storage, etc.) are preserved.
+
+<p>
+ An arbitrary CORBA orb may not support thread identity. The id can be inserted into
+ the service context list. If the CORBA process supports it, it is fine, if not
+ thread identity cannot be preserved, this could result in deadlocks.
+
+<p>
+ The service context id <em>LogicalThreadId</em> can be reused, that was original
+ designed for DCOM interoperability. An appropriate ID for this should be applied at
+ the omg.
+</p>
+
+<h4><a name="object_identity">Object identity</a></h4>
+<p>CORBA does not guarantee object identity , but several UNO interfaces
+ (especially container and broadcaster/listener interfaces) rely on that. I
+ would like to introduce a typical example, where such a problem occurs.</p>
+
+<table BORDER=0 CELLSPACING=0 CELLPADDING=4 WIDTH="100%" >
+<tr>
+<td COLSPAN="3" WIDTH="100%" BGCOLOR="#FFFFC0">
+<pre>
+interface XListener : XInterface
+{
+...
+};
+
+interface XBroadcaster : XInterface
+{
+ void addListener( [in] XListener listener );
+ void removeListener( [in] XListener listener );
+}
+</pre>
+</td>
+</tr>
+</table>
+
+<p>The XBroadcaster interface is implemented by the UNO object U (in the UNO
+ process), the XListener interface is implemented by the CORBA object C in
+ the CORBA process. Now there is an actor, that wants to add C into U and
+ later remove C from U.</p>
+
+ <p>
+ Adding is no problem, but removing is. The CORBA bridge in the UNO process must know,
+ that the reference passed with the removeListener() method, is the same, that was
+ passed with the addListener() method. However, it can't know for sure just by seeing
+ the object reference, because in CORBA it is possible, that two object references
+ denote one object.
+
+ <p> The problem is even worse, because the removal may work most of the time
+ (object references passed by add/remove are identical),
+ but sometimes not.
+
+ <p> Note, that the check for object identity in UNO is done by comparing the
+ pointer of the XInterface proxy. So a UNO-CORBA bridge must ensure,
+ that interfaces belonging to the same object get the same proxy. This must be
+ done for every interface reference, because the bridge does not know in advance,
+ if there will be a check for object identity.
+
+ <p>
+ Possible solutions for this problem are :
+
+ <ol>
+ <li><p>Leave the problem of the object identity to the CORBA developer.
+ The UNO-base interface XInterface gets a new method in CORBA :</p>
+<table BORDER=0 CELLSPACING=0 CELLPADDING=4 WIDTH="100%">
+<tr>
+<td COLSPAN="3" WIDTH="100%" BGCOLOR="#FFFFC0">
+<pre>
+interface XInterface
+{
+ any queryInterface( [in] Type type );
+ [oneway] void acquire();
+ [oneway] void release();
+ /**
+ returns an ID, that uniquely identifies this object.
+
+ The ID must be globally unique, e.g. a GUID.
+ */
+ sequence< byte > getCorbaID();
+};
+</pre>
+</td>
+</tr>
+</table>
+ <p>Every time, an object is mapped from CORBA to UNO, the UNO-CORBA bridge
+ checks, if it knows
+ the reference already. If it is new, it calls getCorbaID() at the object.
+ In case, the bridge knows the object already, the existing proxy is
+ used, so that object identity is guaranteed.
+ </p>
+
+ <p>This works (as long as a unique id is provided), but it may be
+ excruciatingly slow for some applications (for every newly mapped
+ interface, 1 remote call is necessary, think of a sequence<
+ XInterface > with 100 elements, and you know what I mean :o) ). This
+ is also a burden for the CORBA developer.</p>
+
+ <p> There are three solutions, to avoid the performance problem
+
+ <ol>
+ <li><p>
+ The UNO-CORBA bridge
+ itself exports the interface XRemoteCorbaBridge interface (how can it be offered
+ to the client?).
+ </p>
+
+<table BORDER=0 CELLSPACING=0 CELLPADDING=4 WIDTH="100%" >
+<tr>
+<td COLSPAN="3" WIDTH="100%" BGCOLOR="#FFFFC0">
+<pre>
+interface XRemoteCorbaBridge
+{
+ [oneway] void associateInstanceWithId(
+ [in] any instance, [in] sequence< byte > corbaID );
+}
+</pre>
+</td>
+</tr>
+</table>
+ <p>In the any, the object reference is inserted, that is going to be mapped
+ in near future.
+ The sequence< byte > contains the id, that would be returned by the
+ getCorbaID()-method.
+ This would lead to the following code (I use UNO C++ notation, because I don't know
+ a CORBA C++ mapping very good):</p>
+<table BORDER=0 CELLSPACING=0 CELLPADDING=4 WIDTH="100%" >
+<tr>
+<td COLSPAN="3" WIDTH="100%" BGCOLOR="#FFFFC0">
+<pre>
+ Reference< XRemoteCorbaBridge > rRemoteCorbaBridge =
+ ... (got from somewhere);
+ Reference< XBroadcaster > rBroadcaster = ...(got from somewhere);
+ Reference< XListener > rListener = ... ( got from somewhere);
+
+ Any myAny;
+ myAny <<= rListener;
+ rRemoteCorbaBridge->associateInstanceWithId(
+ myAny, rListener->getCorbaID() );
+ rBroadcaster->addListener( rListener );
+
+ // and later
+ ...
+
+ rRemoteCorbaBridge->associateInstanceWithId(
+ myAny, rListener->getCorbaID() );
+ rBroadcaster->removeListener( rListener );
+</pre>
+</td>
+</tr>
+</table>
+ <p>(The second associateInstanceWithId call is not necessary, when the same
+ reference is used).</p>
+
+ <p>One advantage of this solution is, that the CORBA developer must only
+ care for the problem, where performance is needed, but it looks quite
+ ugly.</p>
+
+ <p>Because CORBA does not guarantee the series of oneway calls, it is not certain
+ , that this will work as expected (but quite likely for most ORB implementations).
+ However as this is only an optimization, the code will still works.
+ </p></li>
+
+ <li><p>The orb could be modified, that it inserts into the IOR a special
+ profile
+ which includes the object identifier. Such a profile must be specified and a
+ tag must be applied at the omg.</p></li>
+
+ <li><p>For every UNO interface, a struct is generated, for example:</p>
+<table BORDER=0 CELLSPACING=0 CELLPADDING=4 WIDTH="100%" >
+<tr>
+<td COLSPAN="3" WIDTH="100%" BGCOLOR="#FFFFC0">
+<pre>
+ struct container_XListener
+ {
+ XListener reference;
+ sequence< byte > corbaId;
+ };
+</pre>
+</td>
+</tr>
+</table>
+ <p>This struct replaces every occurrence of an interface reference such a way,
+ that e.g. the XBroadcaster interface looks like</p>
+<table BORDER=0 CELLSPACING=0 CELLPADDING=4 WIDTH="100%" >
+<tr>
+<td COLSPAN="3" WIDTH="100%" BGCOLOR="#FFFFC0">
+<pre>
+interface XBroadcaster : XInterface
+{
+ void addListener( [in] struct container_XListener listener );
+ void removeListener( [in] struct container_XListener listener );
+}
+</pre>
+</td>
+</tr>
+</table>
+ <p>The CORBA developer must then fill the struct with the correct id before
+ passing it to a UNO. Using no id might signal, that the caller does not care
+ about object identity for this object.</p></li>
+ </ol>
+ <li><p>Remove all API in UNO, that relies on object identity and erase
+ those interfaces. There is currently a lot of code relying on this.
+ It does not seem to be possible in near future.</p></li>
+
+ <li><p>For every mapped interface, a new proxy is generated, object
+ identity would never work. Thus, the above API is not useable for the
+ CORBA programmer.</p></li>
+
+ <li><p>A clever proxy for such a container interface is used in the UNO
+ process.</p>
+
+<table BORDER=0 CELLSPACING=0 CELLPADDING=4 WIDTH="100%" >
+<tr>
+<td COLSPAN="3" WIDTH="100%" BGCOLOR="#FFFFC0">
+<pre>
+interface XBroadcasterProxy : XInterface
+{
+ long addListener( [in] XListener listener );
+ void removeListener( [in] long id );
+}
+</pre>
+</td>
+</tr>
+</table>
+ <p>The XBroadcasterProxy implementation is connected to the
+ XBroadcaster implementation somehow before (it may be a separate
+ service). The XBroadcasterProxy.addListener implementation adds
+ XListener-Proxies to the XBroadcaster implementation and stores a hash
+ id, which is returned to the original actor. This actor can later
+ remove the interface at the XBroadcasterProxy implementation using the
+ returned id.</p>
+
+ <p>
+ The broadcaster proxy must certainly be implemented generically, so that it
+ can be reused as often as possible.
+
+ <p>
+ This works in the concrete example, but does not solve all problems.
+ If the interface reference of C is passed to an object in the UNO process,
+ and this object inserts it into a container, the same problem may occur.</p>
+
+ <p>We are currently looking for a better solution. Any suggestions?</p>
+
+
+<h4><a name="unknown_xinterface_mapping">
+Mapping <code>GNOME::Unknown</code> and <code>com::sun::star::uno::XInterface</code>
+</a></h4>
+<p>As a result of the above discussion on object identity and object lifetime,
+the following rules can be obtained :</p>
+
+<ul>
+<li><p>All CORBA interfaces seem to be derived from XInterface in the UNO
+process. The typelibrary needs to be extended, so that the CORBA-UNO bridge can
+identify, whether a given interface has its origin in CORBA or in UNO.</p></li>
+<li><p>All UNO interfaces appear in CORBA as derived from XInterface, but
+XInterface gets the additional getCorbaId() method.</p></li>
+
+<li><p>All CORBA interfaces derived from <code>GNOME::Unknown</code> appear in
+UNO only as derived from <code>com::sun::star::uno::XInterface</code>, the
+<code>GNOME::Unknown</code> interface does not appear. The typelibrary needs to
+be extended, so that the CORBA-UNO bridge can identify, that the GNOME::Unknown
+interface is the real base interface.</p></li>
+</ul>
+
+<h4><a name="multiple_inheritance">Multiple inheritance</a></h4>
+Multiple inheritance will not be supported in the first version of the UNO-CORBA bridge.
+
+<h4><a name="type_information">Type information</a></h4>
+<p>Both processes (UNO and CORBA) must have the same type information
+available. In UNO, these types must be accessible via the typelibary. The
+CORBA-UNO bridge will generically marshal these calls without the need of
+generated code. On CORBA side, there must be (in general) libraries of
+generated stub/proxy code available.</p>
+</ol>
+
+<h2 id="implementation_concepts"> Implementation concepts </h2>
+
+<!-- ************************ C O N C E P T S ************************* -->
+
+<h4><a name="object_identifier">Object identifier</a></h4>
+ What object identifiers get incoming CORBA objects within UNO and what
+ object ids get outgoing UNO objects?
+ <p>
+ As there is currently no better proposal for the
+ <a href="#object_identity">object identity problem</a>, we assume that
+ solution 1. is chosen.
+
+ <p>
+ First the mapping of UNO objects to CORBA is discussed. Below you find a typical example of
+ an UNO object implementing multiple interfaces.
+ <p>
+
+ <img src="../images/pipe_inheritance.gif" alt="Pipe inheritance"/>
+
+ <p>
+ The Pipe object is instantiated in the UNO process and is passed
+ as an XInterface reference to the CORBA-process.
+
+ <p>
+ In CORBA, object references contain the most derived type and (beside other things)
+ an unique object identifier.
+ A request can be invoked by sending the unique
+ object identifier (and thus leaving out the type information). As there is no
+ most derived type in UNO, the UNO-CORBA
+ bridge must be able to extract solely from the object identifier, which object and
+ which interface the request is meant for.
+
+ <p>
+ The bridge could use the UNO object identifier and try to find out by the
+ method name, which interface shall be called on.
+ But this would mean that it is not possible to have two methods with the same
+ name in two different interfaces.
+
+ <p>
+ So the UNO-CORBA bridge should use the UNO object identifier as an prefix and adds a type
+ identifier. The type identifier may either be the complete type name or a single byte
+ (the bridge ensures the byte's uniqueness for every single object ).
+ <p>
+
+ So in the above example, if the UNO object identifier is "leo", the CORBA
+ object identifier could be
+
+ <table>
+ <tr><th>Object ID</th><th>type name</th></tr>
+ <tr><td>leo0</td><td><code>XInterface</code></td></tr>
+ <tr><td>leo1</td><td><code>XInputStream</code></td></tr>
+ <tr><td>leo2</td><td><code>XOutputStream</code></td></tr>
+ </table>
+
+ <p>For persistent object references, the name given to the object when
+ inserting it into the bridge is used (Note that this will only be done for
+ the exact type, other interfaces of the persistent object will have
+ transient ids), so for persistent references, there is no type suffix.</p>
+
+<p>
+ Now the mapping of CORBA objects to UNO is discussed. If an CORBA object implements UNO
+ interfaces, the object must implement a <code>getCorbaId()</code> method.
+ The bridge calls this method and uses the return value as unique object identifier.
+
+ <p>
+ For CORBA objects implementing CORBA interfaces, the bridge itself must generate an object
+ identifier. It may happen that the same object gets different object identifiers, because
+ the CORBA-UNO bridge has no possibility get the id of the object. So object identity for
+ these objects will not work in UNO. However, the bridge must ensure, that an identifier
+ is unique, therefor it is not sufficient to use the CORBA object identifier (two
+ different CORBA processes may use the same identifier). Therefor an connection dependent
+ prefix is added to the object identifier (maybe a GUID generated for every connection).
+
+
+<h4><a name="corba_bridge_service"> CorbaBridge service</a></h4>
+ The CorbaBridge service is the interface between the UNO developer and the
+ core bridge. In general, this service is used at startup and shutdown
+ of the bridge.
+
+ <p>
+ What does the bridge need?
+
+ <ul>
+ <li><p>Port and host, that shall be inserted in outgoing TRANSIENT
+ object references.</p></li>
+ <li><p>Port and host, that shall be inserted in outgoing PERSISTENT
+ object references. Here the host/port number of an implementation
+ repository may be entered.</p></li>
+ <li><p>Port and host, that the shall be listened to. There may be multiple
+ host/port combinations. Note that in outgoing object references only
+ one host/port can be inserted ! If you want two different hosts/ports
+ on two different transient object references, you need two instances
+ of a CORBA bridge.</p></li>
+ <li><p>Access to acceptor and connector services, that allow the bridge to
+ accept incoming connections and to establish outgoing connections, if
+ needed.</p></li>
+ <li><p>Objects, that shall be mapped persistently. It should be possible
+ to make object references persistent. Persistent object references
+ stay the same even if the server process is restarted. To achieve
+ this, the bridge must know the objects before accepting calls. This
+ is for two reasons : If an incoming request to such an object comes
+ in, the bridge must know, where to delegate it. If the persistent
+ object is mapped, it must marshal the persistent reference instead of
+ the transient one.</p></li>
+ </ul>
+
+ <p>Below you can find a first possible draft of the interface. No error
+ handling yet specified.</p>
+
+<table BORDER=0 CELLSPACING=0 CELLPADDING=4 WIDTH="100%" >
+<tr>
+<td COLSPAN="3" WIDTH="100%" BGCOLOR="#FFFFC0">
+<pre>
+struct PersistentInstance
+{
+ string Name;
+ any instance;
+};
+
+interface XCorbaBridge : XInterface
+{
+ /** allows the bridge to listen on multiple ports
+ */
+ void addAcceptor( [in] XAcceptor acceptor, [in] string acceptString );
+ void removeAcceptor( [in] XAcceptor acceptor );
+
+ /** the bridge calls uses this connector, to
+ establish interprocess connections.
+ */
+ void setConnector( [in] XConnector connector );
+
+ /** the reply address is inserted in transient object references.
+ */
+ void setTransientReplyAddress( [in] string connectionString );
+ void addTransientObject( [in] any instance );
+
+ void setPersistentReplyAddress( [in] string connectionString );
+
+ void addPersistentObject( [in] string objectName, [in] any instance );
+ void removePersistentObjectByName( [in] string objectName );
+ sequence < struct PersistentInstance > getPersistentObjects();
+
+ /**
+ Removes either transient or persistent objects.
+
+ The object must have been added before either by addTransientObject or addPersistentObject.
+ */
+ void removeObject( [in] any instance );
+
+ /**
+ returns a stringified IOR, that an arbitrary orb may use to connect to this object.
+
+ The object must have been added before either by addTransientObject or addPersistentObject or
+ has been mapped before from a CORBA process.
+ */
+ string getIORForObject( [in] any instance );
+
+ /** allows retrieval of an object from a arbitrary CORBA process using a stringified IOR.
+ */
+ any resolveByIOR( [in] string sName );
+
+
+ /**
+ Sets corba bridge into an inactive state. All calls are suspended, no connections
+ are accepted.
+
+ After instantiation, the bridge is in a suspended mode. One may mush to switch to
+ suspended mode again, when multiple changes shall be applied to the bridge
+ parameters consistently.
+ */
+ void suspend();
+
+ /**
+ Sets corba bridge into an active state. Connections can be accepted, calls
+ are processed.
+
+ After instantiation, the bridge is in a suspended mode.
+ */
+ void resume();
+
+ /** Shutdown the bridge. All connections are interrupted, all instances are released.
+
+ @param waitForCompletion if true, the method waits until all threads have gone.
+ if false, the method returns immediately. ( This may be
+ necessary, if the method is called from a remote process ).
+
+ */
+ void shutdown( [in] boolean waitForCompletion);
+};
+
+service CorbaBridge
+{
+ interface XCorbaBridge;
+};
+</pre>
+
+</td>
+</tr>
+</table>
+
+<h4><a name="connection_management">Interprocess connection management</a></h4>
+ A normal UNO-UNO interprocess bridge just owns one interprocess connection. This
+ is not appropriate for the UNO-CORBA bridge, because interface references handed out
+ over one connection can come in again over a different connection and must still be
+ valid, so all connections must end in one bridge.
+<p>
+ The UNO-CORBA bridge needs to distinct between connections initiated from
+ the UNO process or from an arbitrary CORBA process. If a request shall be invoked
+ on a object, that has not been invoked before, the IOR must be parsed for a
+ host/port combination. The bridge has a hashmap for actively initiated
+ connections. The key is host/port and the connection is the value.
+<p>
+ If there is no match, the bridge tries to initiate a connection. On success,
+ the connection is added to the hashmap. The proxy should store that it got
+ the object last time over this connection for performance reasons.
+
+<p>
+ Actively initiated connections can be closed at any time. This should
+ be done, when the last proxy, that uses this connection, dies.
+
+<p>
+ Passively initiated connections should be closed by the remote process. Another
+ possibility would be to close it when the last stub for this connection dies, however
+ then a CloseConnection message must be sent.
+
+<p>
+ Bidirectional communication (as specified by GIOP 1.2) should be ignored in the
+ first run, because it complicates things a lot.
+
+<h4><a name="iiop_version">IIOP versions</a></h4>
+ I think IIOP versions 1.0 is sufficient for the first running ORB. The following features
+ are added in the following versions :
+
+ <ul>
+ <li> Version 1.1
+ <ul>
+ <li><p>Fragmentation messages</p></li>
+ </ul>
+ </li>
+ <li> Version 1.2
+ <ul>
+ <li><p>Bidirectional communication over one connection</p></li>
+ </ul>
+ </li>
+ </ul>
+
+In the first run, only version 1.0 should be supported. Keeping the versions
+1.1 and 1.2 in mind during implementation, it should be quite easy to implement
+them later if needed.
+
+
+<h4><a name="deployment_problem">
+How can the CORBA-UNO bridge be deployed for the GNOME orbit?
+</a></h4>
+<p>(prebuilding stub/proxy code?, which compiler to use?, where to put the
+libraries?, how do we get the UNO types into the typelibrary?)</p>
+<table summary="footer" width=100% bgcolor=#666699>
+<tr><td>
+<font color="#FFFFFF">
+Author:
+<a href="mailto:joerg.budischewski@germany.sun.com">Joerg Budischewski</a>,
+<a href="mailto:juergen.schmidt@germany.sun.com">Jürgen Schmidt</a>
+($Date: 2004/11/27 08:10:06 $)
+<br/><I>Copyright 2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.</I></font>
+</td></tr>
+</table>
+</body>
diff --git a/content/udk/common/man/concept/uno_default_bootstrapping.html b/content/udk/common/man/concept/uno_default_bootstrapping.html
new file mode 100644
index 0000000..faa7332
--- /dev/null
+++ b/content/udk/common/man/concept/uno_default_bootstrapping.html
@@ -0,0 +1,12 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+"http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+ <meta http-equiv="refresh" content="3; URL=http://wiki.services.openoffice.org/wiki/Uno/Binary/Spec/Bootstrapping" />
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+<p class="Header">Redirecting....</p>
+
+</body>
+</html>
diff --git a/content/udk/common/man/concept/uno_langbind.html b/content/udk/common/man/concept/uno_langbind.html
new file mode 100644
index 0000000..6a1cdc1
--- /dev/null
+++ b/content/udk/common/man/concept/uno_langbind.html
@@ -0,0 +1,181 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<HTML>
+<HEAD>
+<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1"/>
+<title> UNO Language Binding : What is it about? </title>
+<style type="text/css">
+ <!--
+h1 { text-align:center; margin-top: 0.2cm; text-decoration: none; color: #ffffff; font-size: 6; margin-top: 0.2cm}
+h2 { margin-top: 0.2cm; margin-bottom=0.1cm; color: #ffffff;
+ background-color: #666699 }
+ul {margin-bottom: 0cm;}
+li {margin-bottom: 0cm;}
+dl {margin-bottom: 0.2cm;}
+dd {margin-bottom: 0.2cm;}
+dt {margin-bottom: 0.2cm;}
+-->
+</style>
+</HEAD>
+
+<body>
+<table width=100% border=0 cellpadding=4 cellspacing=0 bgcolor="#666699"
+ summary="Header">
+<TR><TD>
+ <h1> UNO Language Binding : What is it about? </h1>
+ </td><td>
+ <A HREF="http://www.openoffice.org/">
+ <img src="../../../images/open_office_org_logo.gif" name="Grafik1" alt="OpenOffice.org" align=right width=109 height=54 border=0/></A>
+ </TD></TR>
+</TABLE>
+
+<h2 id=contents> Contents </h2>
+<blockquote>
+ <a href="#intro">Introduction</a><br/>
+ <a href="#def">Definitions:</a>
+ <ul>
+ <li><a href="#env">UNO Runtime Environment (URE)</a></li>
+ <li><a href="#langspec">Language Specification and Glue Code</a></li>
+ <li><a href="#codegen">Code Generator</a></li>
+ <li><a href="#bridge">UNO Bridge</a>
+ <ul>
+ <li><a href="#mapping">Mapping</a></li>
+ <li><a href="#engine">Environment/ Engine Access</a></li>
+ </ul>
+ </li>
+ <li><a href="#loader">UNO Component Loader</a></li>
+ <li><a href="#bootstrap">Bootstrapping</a></li>
+ <li><a href="#initobject">Initial Object</a></li>
+ </ul>
+</blockquote>
+
+<h2 id="intro"> Introduction </h2>
+
+<p>
+The objective of this document is to get a general notion of a UNO language
+binding and
+define terminology of the parts that language binding consists.
+For <a href="http://wiki.services.openoffice.org/wiki/Uno/Cpp/Tutorials/Introduction_to_Cpp_Uno">general UNO programming</a> or details
+ about <a href="../../../cpp/man/cpp_bridges.html">building up a C++ bridge</a>,
+for example for a specific C++ compiler please read the specific documents.</p>
+
+<p>A UNO language binding is simply said the infrastructure enabling communication between
+UNO components from different language or runtime environments.
+More over a language binding not only let components, for example written with different
+programming languages, to interoperate, it also provides the UNO programming environment
+for a specific language/ environment.
+Despite the fact that a language binding may not only connect different programming languages
+(for example when connecting to object models like COM), we use the term of a "language
+binding" for simplicity. Though, the term "Environment binding" would have been more general.</p>
+
+<p>The following section presents several definitions of what parts a UNO
+language binding consists. Some parts are optional, though.
+
+<h2 id="def"> Definitions </h2>
+
+<p><i><b><a name="env"></a>UNO Runtime Environment (URE).</b></i>
+A UNO component runs in an environment which serves as the platform to run
+components (UNO Runtime Environment).
+A language binding connects two environments for interoperation.
+<p>
+The runtime prerequisites for components in an environment may be different,
+for example a java component needs a java virtual machine, a COM component the COM libraries.
+An environment need not denote a specific programming language to interoperate with,
+it can even be a language independent object model like COM.
+</p>
+
+<p><b><i><a name="langspec"></a>Language Specification and Glue Code.</i></b>
+The language specification defines the mapping of any UNO type (for example IDL long)
+to its corresponding environment specific type (for example java int).
+More over, the handling of complex types (for example structs, sequences, any, interfaces)
+is defined with respective support by a runtime API.
+If a programming language does not support a specific UNO feature (for example no
+"direct"/ convenient exception support), additional glue code (part of the runtime API)
+has to be defined balancing out these weaknesses.
+</p>
+
+<p><i><b><a name="codegen"></a>Code Generator.</b></i>
+The language specification defines the representation of UNO IDL types.
+
+<p>A code generator produces the appropriate programming language constructs as
+defined in the language specification.
+It commonly reads from a binary type library and writes out files for each type.
+</p>
+
+<p><i><b><a name="bridge"></a>UNO Bridge.</b></i>
+A bridge is the core instance connecting two environments.
+
+<p>A bridge is bidirectional in the way that it can map interfaces from one
+environment
+to another and vice versa, thus providing two unidirectional mappings.</p>
+
+<blockquote>
+<p><i><b><a name="mapping"></a>Mapping.</b></i>
+Mapping an interface involves in depth knowledge of both environments
+to emulate arbitrary interfaces.
+
+<p>Calls on an emulated interface are delegated (including marshalling) via the
+bridge and lead to a method invocation on the target interface.
+Any return values, out parameters or exceptions have to be converted to the calling environment.
+For this task the complementary mapping is needed,
+thus both mappings of a bridge are tied closely together.
+</p>
+
+<p><i><b><a name="engine"></a>Environment/ Engine Access.</b></i>
+The bridge needs runtime environment access, for interpreting environments
+also access to the executing engine (for example java, javascript).
+<p>The bridge connecting to the environment commonly needs engine access, too.
+</p>
+</blockquote>
+
+<p><i><b><a name="loader"></a>UNO Component Loader.</b></i>
+The UNO component loader loads a UNO component implemented for a specific UNO runtime environment.
+<p>Besides loading the component and preparing the runtime environment (like scripting engine access),
+this process eventually includes raising an appropriate bridge to connect to the environment.
+
+<p>When loading a component, the component may define own types it needs to execute.
+These types may be introduced to the runtime by the component dynamically at startup
+or those types have been merged to a central binary typelib file prior to application execution
+(which has been most commonly used for now).
+</p>
+
+<p><i><b><a name="bootstrap"></a>Bootstrapping.</b></i>
+The bootstrapping process starts up the UNO core system up to the point that components
+can be loaded and executed.
+
+<p>Components are dependent on each other. For loading components you most commonly need to have
+a component loader component from scratch. This is the first problem: You need to load
+it manually.
+Among other things it is necessary to have a type system providing type information used
+in components. The latter issue may includes typelib files to be known.
+So this process requires inside implementation knowledge of the initial components,
+despite the fact that you normally need not know how a service is implemented.
+As a result of the bootstrapping process, it is possible to raise further components
+without knowing any implementation details.
+
+<p>
+It is not intended to define a <i>general</i> bootstrap process here, if this is possible at all.
+Although, we will present a default scheme applications using
+the C++ implementations of base services from code module <code>stoc</code>.
+It is part of the UNO language binding to provide a mechanism to bootstrap an initial
+UNO system in a specific UNO runtime environment.
+</p>
+
+<p><i><b><a name="initobject"></a>Initial Object.</b></i>
+First object provided by a UNO runtime environment.
+
+<p>This may be necessary in inter-process communication, if the component
+loader needs to
+have a "special" initial object like a service manager.
+The language binding has to define the initial communication protocol to get the initial object.
+</p>
+
+<table summary=Footer bgcolor=#666699 width=100%>
+<TR><TD><P><FONT COLOR="#ffffff">
+Author: <A HREF="mailto:Daniel.Boelzle@germany.sun.com">
+<FONT COLOR="#ffffff">Daniel Bölzle</font></A>. ($Date: 2007/05/25 14:38:49 $)<br/>
+ <I>Copyright 2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.</I>
+</FONT>
+</TD></tr>
+</TABLE>
+</BODY>
+</HTML>
diff --git a/content/udk/common/man/concept/uno_security.html b/content/udk/common/man/concept/uno_security.html
new file mode 100644
index 0000000..fbecb13
--- /dev/null
+++ b/content/udk/common/man/concept/uno_security.html
@@ -0,0 +1,675 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+<head>
+<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
+<TITLE>
+UNO Security
+</TITLE>
+</head>
+<body LINK="#444488" VLINK="#444488" BGCOLOR="#ffffff"><A NAME="__Top__"></A>
+<TABLE WIDTH=100% BORDER=0 CELLPADDING=4 CELLSPACING=0>
+<COL WIDTH=75>
+<TR><TD BGCOLOR="#666699">
+ <H1 ALIGN=CENTER><A HREF="http://www.openoffice.org/">
+ <IMG SRC="../../../images/open_office_org_logo.gif" NAME="Grafik1" ALT="OpenOffice.org" ALIGN=RIGHT WIDTH=109 HEIGHT=54 BORDER=0>
+ </A><FONT COLOR="#ffffff">UNO Security</FONT></H1>
+ </TD></TR>
+
+</TABLE>
+<br>
+
+<TABLE BORDER=0 CELLPADDING=4 CELLSPACING=0>
+<TR><TD BGCOLOR="#666699">
+ <H3><FONT COLOR="#ffffff" SIZE=4>
+ Contents</FONT></H3>
+</TD></TR>
+
+ <TR>
+ <TD>
+ <p><a href="#intro">Introduction</a></p>
+ <p><a href="#api">Concept and API</a>
+ <ul>
+ <li><a href="#api_access">API access</a></li>
+ <li><a href="#checking_permissions">Checking Permissions</a>
+ <ul>
+ <li><a href="#filepermission">FilePermission</a></li>
+ <li><a href="#socketpermission">SocketPermission</a></li>
+ <li><a href="#runtimepermission">RuntimePermission</a></li>
+ <li><a href="#allpermission">AllPermission</a></li>
+ </ul>
+ </li>
+ <li><a href="#static_restrictions">Static Restrictions</a></li>
+ <li><a href="#dynamic_restrictions">Dynamic Restrictions</a></li>
+ <li><a href="#ac_switches">AccessController Switches</a></li>
+ </ul>
+ <p><a href="#overview">Overview</a></p>
+ <p><a href="#untrusted">Dealing with Untrusted Code</a></p>
+ <ul>
+ <li><a href="#untrusted_native">Untrusted Native Code</a></li>
+ <li><a href="#untrusted_scripted">Untrusted Scripted Code</a></li>
+ <li><a href="#untrusted_java">Untrusted Java Code</a></li>
+ <li><a href="#untrusted_remote">Untrusted Inter Process Code</a></li>
+ </ul>
+ <p><a href="#current_implementation">Current Implementation Details</a></p>
+ <ul>
+ <li><a href="#recurring_calls">Recurring Calls</a></li>
+ <li><a href="#performance_considerations">Performance Considerations</a></li>
+ <li><a href="#file_policy">File Policy Implementations</a></li>
+ </ul>
+ <p><a href="#todos">Things left to do...</a></p>
+ </TD>
+ </TR>
+
+<TR><TD BGCOLOR="#666699">
+ <H3><FONT COLOR="#ffffff" SIZE=4>
+ <a name="intro">Introduction</a></FONT></H3>
+</TD></TR>
+<TR><TD>
+ <p>
+In general, security concerns the following four topics [CORBA Security Specification]:
+<ul>
+ <li><p><b>Confidentiality:</b> Information is disclosed only to users authorized to
+ access it.</p></li>
+ <li><p><b>Integrity:</b> Information is modified only by users who have the
+ right, only in authorized ways, and is transferred only between intended
+ users in intended ways.</p></li>
+ <li><p><b>Accountability:</b> Users are accountable for their
+ security-relevant actions.</p></li>
+ <li><p><b>Availability:</b> Use of the system cannot be randomly or
+ maliciously denied to authorized users.</p></li>
+</ul>
+Among this very common understanding of security, there are two distinct topics when users want to access or modify resources, or execute a program:
+<p>
+<b>Authentification:</b> The process of validating a subject to ensure that the subject (for example John Doe) is who or what it claims to be.</p>
+<p><b>Authorization:</b> The process of granting permission to access data or execute functionality.
+</p>
+<p>
+A subject (for example the user who started an application or demands access on
+resources accessible via a WWW front end) has to be authenticated to an
+information system. Often, this first step associates the subject with a set of
+credentials, such as, user attributes, permissions, or different principals.
+A subject may be any entity, for example, a person or service. Once
+authenticated, a subject is populated with associated identities or principals.
+A subject may have many principals. For example, a person may have a name
+principal ("John Doe") and a social security number principal ("123-45-6789"),
+which distinguish it from other subjects.</p>
+<p>Authorization has to be done any time the user demands access to sensitive
+data or wants to execute sensitive code. Authorization is hence of a
+programmatic nature and is implemented by the specific service that is handling
+the demand (explicitly checked by base service, but implicitly checked from
+service users' perspective). A common approach of authorization is handled by
+access control lists (ACL), that is, sets of permissions (positive) or denials
+(negative).
+</p>
+<img src="../images/sec_resource.jpg">
+<p>
+The next sections are about the UNO security API, covering authorization exclusively. Authorization is a primary goal because it affects most of the client code, such as, doing permission checks.
+It is assumed that users have been authenticated previously using some
+mechanism.</p>
+<p>There was no new API defined that abstracted from a specific authentication mechanism, such as the Java Authentication and Authorization framework (JAAS).
+Although there is no defined API, you can find some draft interfaces and services in the udkapi cvs tree of the <code>com.sun.star.security.auth</code> package.
+
+</p>
+</td></tr>
+
+<TR><TD BGCOLOR="#666699">
+ <H3><FONT COLOR="#ffffff" SIZE=4>
+ <a name="api">Concept and API</a></FONT></H3>
+</TD></TR>
+<TR><TD>
+<p>The UNO API is closely related to the Java authorization API. Permission
+semantics have been adopted.
+For details about java permissions, have a look at <a href="http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html">
+Permissions in the Java 2 SDK</a>.</p>
+<p>There is only a difference when coming to dynamic restrictions which are
+implicitly handled by the Java AccessController (ac). The Java ac implicitly
+checks permissions related to a PermissionDomain. A PermissionsDomain includes
+a set of permissions related to a set of classes. Java can manage this, but
+this feature is not practically adaptable for compiled machine code.</p>
+<p>As a solution, these dynamic restrictions can be set explicitly using the
+UNO ac interface. This will install thread/task local restrictions to be used
+upon permission checks.</p>
+
+<p><a name="api_access"><b>API Access</b></a></p>
+<p>Implementing programmatic security (client code), there is an ac singleton object in the component context given to every component. The name of the object is</p>
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+/singletons/com.sun.star.security.theAccessController
+</pre></td></tr></table>
+<p>This object mainly exports the <code>com.sun.star.security.XAccessController</code> interface which has the following <a href="../../common/ref/com/sun/star/security/XAccessController.html">IDL definition</a>:</p>
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+module com { module sun { module star { module security {
+
+interface XAccessController : com::sun::star::uno::XInterface
+{
+ void checkPermission(
+ [in] any perm )
+ raises (AccessControlException);
+
+ any doRestricted(
+ [in] XAction action,
+ [in] XAccessControlContext restriction )
+ raises (com::sun::star::uno::Exception);
+
+ any doPrivileged(
+ [in] XAction action,
+ [in] XAccessControlContext restriction )
+ raises (com::sun::star::uno::Exception);
+
+ XAccessControlContext getContext();
+};
+
+}; }; }; };
+</pre></td></tr></table>
+
+<p><a name="checking_permissions"><b>Checking Permissions</b></a></p>
+<p>The first method is commonly called by security-related services which need to check if an action is permitted.
+The actual permission takes the security policy, currently in effect, into account.
+In general, the <em>security policy in effect</em> has a dynamic and static part.
+The dynamic part uses restrictions modified by <code>doRestricted()</code> and <code>doPrivileged()</code> calls, while the static part takes user credentials into account (commonly persistent data).
+Currently, four different permission types are defined in IDL and implemented in the UDK ac (module <code>stoc/source/security</code>):
+<ul>
+
+<li><p><b><a name="filepermission" href="../../common/ref/com/sun/star/io/FilePermission.html">com.sun.star.io.FilePermission</a></b>:</p>
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+module com { module sun { module star { module io {
+
+struct FilePermission
+{
+ string URL;
+ string Actions;
+};
+
+}; }; }; };
+</pre></td></tr></table>
+<p>This permission represents access to a file or directory.
+A FilePermission consists of a file url and a set of actions valid for that url.
+<p>
+ The path of the file url that ends in <code>"/*"</code> indicates all the files and
+ directories contained in that directory. A path that ends with <code>"/-"</code>
+ indicates (recursively) all files and subdirectories contained in that
+ directory. A file url string consisting of the special token <code>"<<ALL FILES>>"</code>
+ matches any file.
+ </p>
+ <p>Note: A file url string consisting of a single <code>"*"</code> indicates all the files
+ in the current directory, while a string consisting of a single <code>"-"</code> indicates
+ all the files in the current directory and (recursively) all files and
+ subdirectories contained in the current directory.
+ </p>
+ <p>The actions to be granted are a list of one or more comma-separated keywords.
+ The possible keywords are <code>"read"</code>, <code>"write"</code>,
+ <code>"execute"</code>, and <code>"delete"</code>.
+ Their meaning is defined as follows:</p>
+ <ul>
+ <li><code>read</code> -- read permission</li>
+ <li><code>write</code> -- write permission</li>
+ <li><code>execute</code> -- execute permission</li>
+ <li><code>delete</code> -- delete permission</li>
+ </ul>
+ <p>The actions string is processed case-insensitive.
+ </p>
+
+ <p><em><b>Attention</b></em>:
+ Be careful when granting FilePermissions. Think about the implications of
+ granting read and especially write access to various files and directories.
+ The <code>"<<ALL FILES>>"</code> permission with write action is especially dangerous.
+ This grants permission to write to the entire file system.
+ </p>
+</li>
+
+<li><p><b><a name="socketpermission" href="../../common/ref/com/sun/star/connection/SocketPermission.html">com.sun.star.connection.SocketPermission</a></b>:</p>
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+module com { module sun { module star { module connection {
+
+struct SocketPermission
+{
+ string Host;
+ string Actions;
+};
+
+}; }; }; };
+</pre></td></tr></table>
+<p>This permission represents access to a network via sockets.
+ A SocketPermission consists of a host specification and a set of actions
+ specifying ways to connect to that host. The host is specified as</p>
+ <pre>
+ host = (hostname | IPaddress)[:portrange]
+ portrange = portnumber | -portnumber | portnumber-[portnumber]
+ </pre>
+ <p>The host is expressed as a DNS name, as a numerical IP address, or as a
+ <code>"localhost"</code> (for the local machine). The wildcard <code>"*"</code>
+ may be included once
+ in a DNS name host specification. If it is included, it must be in the
+ leftmost position, as in <code>"*.sun.com"</code>.
+ </p>
+ <p>The port or portrange is optional. A port specification of the form <code>"N-"</code>,
+ where <code>N</code> is a port number, signifies all ports numbered <code>N</code> and above,
+ while a specification of the form <code>"-N"</code> indicates all ports numbered
+ <code>N</code> and below.
+
+ <p>
+ The possible ways to connect to the host are
+ <ul>
+ <li><code>accept</code></li>
+ <li><code>connect</code></li>
+ <li><code>listen</code></li>
+ <li><code>resolve</code></li>
+ </ul>
+ <p>The <code>"listen"</code> action is only meaningful when used with <code>"localhost"</code>.
+ The <code>"resolve"</code> (resolve host/ip name service lookups) action is implied when any of the other actions are present.
+ </p>
+ <p>As an example of the creation and meaning of SocketPermissions, note that if
+ the following permission:
+<pre>
+SocketPermission("foo.bar.com:7777", "connect,accept");
+</pre>
+ <p>is granted, it allows to connect to port 7777 on foo.bar.com, and to
+ accept connections on that port.
+ </p>
+ <p>Similarly, if the following permission:</p>
+<pre>
+SocketPermission("localhost:1024-", "accept,connect,listen");
+</pre>
+ <p>is granted, it allows that code to accept connections on, connect to, or listen
+ on any port between 1024 and 65535 on the local host.
+ </p>
+
+ <p><em><b>Attention</b></em>:
+ Granting code permission to accept or make connections to remote hosts may be
+ dangerous because malevolent code can then more easily transfer and share
+ confidential data among parties who may not, otherwise, have access to the data.
+ </p>
+</li>
+
+<li><p><b><a name="runtimepermission" href="../../common/ref/com/sun/star/security/RuntimePermission.html">com.sun.star.security.RuntimePermission</a></b>:</p>
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+module com { module sun { module star { module security {
+
+struct RuntimePermission
+{
+ string Name;
+};
+
+}; }; }; };
+</pre></td></tr></table>
+<p>This permission grants runtime access to some named functionality. A RuntimePermission contains
+ a name (also referred to as a <em>target name</em>) but no actions list;
+ you either have the named permission or you don't.
+</p></li>
+
+<li><p><b><a name="allpermission" href="../../common/ref/com/sun/star/security/AllPermission.html">com.sun.star.security.AllPermission</a></b>:</p>
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+module com { module sun { module star { module security {
+
+struct AllPermission
+{
+};
+
+}; }; }; };
+</pre></td></tr></table>
+<p>The AllPermission is a permission that implies all other permissions.</p>
+
+ <p><em><b>Attention</b></em>:
+ Granting AllPermission should be done with extreme care, as it implies all
+ other permissions. Thus, it grants code the ability to run with security
+ disabled. Extreme caution should be taken before granting such a
+ permission to code. This permission should be used only during testing,
+ or in extremely rare cases where an application is completely trusted and
+ adding the necessary permissions to the policy is prohibitively cumbersome.
+ </p>
+</li>
+
+</ul>
+
+<p>When access is denied upon calling <code>checkPermission()</code>, an
+<code>AccessControlException</code> is thrown. An
+<code>AccessControlException</code> signals a security violation.
+The <code>AccessControlException</code> is derived from
+<code>SecurityException</code> which is derived from
+<code>RuntimeException</code> and thus can be thrown upon any call on UNO
+interfaces, except for calls on <code>XInterface::acquire()</code> and
+<code>XInterface::release()</code>.</p>
+
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+module com { module sun { module star { module uno {
+
+exception SecurityException : com::sun::star::uno::RuntimeException
+{
+};
+
+}; }; }; };
+
+module com { module sun { module star { module security {
+
+exception AccessControlException : com::sun::star::uno::SecurityException
+{
+ any LackingPermission;
+};
+
+}; }; }; };
+</pre></td></tr></table>
+
+<p><a name="static_restrictions"><b>Static Restrictions</b></a><br>
+A restriction is defined by a set of permissions. It has to be assured that a demanded permission is implied by this set of permissions.
+Static restrictions are defined by a (commonly persistent) set of permissions granted to a user. This has been done by some admin frontend in advance. The effective set of permissions is provided by the
+<a href="../../common/ref/com/sun/star/security/Policy.html">Policy</a> service.
+There is a singleton object installed into the initial component context from which an ac implementation reads:</p>
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+/singletons/com.sun.star.security.thePolicy
+</pre></td></tr></table>
+<p>The service supports the interface
+<a href="../../common/ref/com/sun/star/security/XPolicy.html"><code>XPolicy</code></a>
+and reads out of some storage:</p>
+
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+module com { module sun { module star { module security {
+
+interface XPolicy : com::sun::star::uno::XInterface
+{
+ sequence< any > getPermissions(
+ [in] string userId );
+ sequence< any > getDefaultPermissions();
+ void refresh();
+};
+
+service Policy
+{
+ interface XPolicy;
+};
+
+}; }; }; };
+</pre></td></tr></table>
+
+<p>Implementing the <code>XPolicy</code> interface, it is important to separate
+default permissions from user permissions. That is, the ac implementation has
+to combine both to get the effective set of permissions. Providing these
+permissions separately, the ac implementation has the opportunity to optimize
+permission sets, that is, it only needs to read (and convert) the default
+permissions once, for every user.</p>
+<!-- When refreshing the user policy, e.g. when some storage contexts were modified, the ac has to be notified. Therefore, it is recommended that the policy supports the
+<a href="../../common/ref/com/sun/star/container/XContainer.html"><code>XContainer</code></a>
+interface. The current ac implementation will support this soon (xxx todo).
+-->
+
+<p><a name="dynamic_restrictions"><b>Dynamic Restrictions</b></a><br>
+Dynamic restrictions apply to the <code>doPrivileged()</code> and <code>doRestricted()</code> calls of the <code>XAccessController</code> interface.
+These calls will directly modify a property of the
+<a href="uno_contexts.html#current_context">current context</a> which is called</p>
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+access-control.restriction
+</pre></td></tr></table>
+
+<p>This property is of type <code>XAccessControlContext</code> and taken into
+account additionally to the static permissions granted to the calling user.</p>
+<p>The <code>XAccessControlContext</code> has only one method:</p>
+
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+module com { module sun { module star { module security {
+
+interface XAccessControlContext : com::sun::star::uno::XInterface
+{
+ void checkPermission(
+ [in] any perm )
+ raises (AccessControlException);
+};
+
+}; }; }; };
+</pre></td></tr></table>
+
+<p>Users may implement this interface themselves to restrict or to get a snapshot of the currently effective security by calling <code>XAccessController::getContext()</code>. This has to be done when raising new threads. A child thread has to inherit an initial restriction context from its parent at the time of creation.</p>
+
+<p>When calling <code>XAccessController::doRestricted()</code> the ac
+implementation combines a previous restriction with the given one, thus the
+intersection of permissions of both contexts becomes effective. It then
+installs this new restriction into the current context and calls the specified
+action. In essence, when doing subsequent <code>doRestricted()</code> calls,
+you chain up several restrictions over several stack layers.</p>
+
+<p>When calling <code>XAccessController::doPrivileged()</code>, the ac
+implementation adds the given set of permission (defined by the ac context),
+installing an extended restriction. If you pass a null-ref to
+<code>doPrivileged()</code>, then all permissions are implied (no dynamic
+restriction). This feature may be sensible for basic service implementations
+which need privileges in a well-defined manner, a.k.a., <em>they know what they
+do</em>.</p>
+<img src="../images/sec_dynamic.jpg">
+
+<p><a name="ac_switches"><b>AccessController Switches</b></a><br>
+The ac can be run in several modes, thus influencing its runtime behavior. When instantiating the ac service, it uses the component context' property</p>
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+/services/com.sun.star.security.AccessController/mode
+</pre></td></tr></table>
+<p>Currently, there are five modes:</p>
+<ul>
+ <li><code>"on"</code><br>
+ This (default) mode turns dynamic and static permission checks on.
+ Dynamic restrictions are performed evaluating the current context's
+ <code>access-control.restriction</code> property. Static
+ permissions are checked against the calling user's permissions
+ provided by the policy service. The current user id is determined
+ using the current context's property
+ <code>access-control.user-credentials.id</code>. If neither the
+ dynamic restriction nor the effective user's permissions grant a
+ demanded permission, then an <code>AccessControlException</code> is
+ thrown.</p></li>
+ <li><p><code>"single-user"</code><br>
+ This mode turns dynamic and static permission checks on. Dynamic
+ restrictions are performed evaluating the current context's
+ <code>access-control.restriction</code> property. Static
+ permissions are checked against the user's permissions provided by
+ the policy service. The user id is determined using the component
+ context's property
+ <code>/services/com.sun.star.security.AccessController/single-user-id</code>.
+ If neither the dynamic restriction nor the effective user's
+ permissions grant a demanded permission, then an
+ <code>AccessControlException</code> is thrown.</p></li>
+ <li><p><code>"single-default-user"</code><br>
+ This mode turns dynamic and static permission checks on. Dynamic
+ restrictions are performed evaluating the current context's
+ <code>access-control.restriction</code> property. Static
+ permissions are checked against the default permissions provided by
+ the policy service. If neither the dynamic restriction nor the
+ default permission grant a demanded permission, then an
+ <code>AccessControlException</code> is thrown.</p></li>
+ <li><p><code>"dynamic-only"</code><br>
+ This mode turns dynamic permission checks on, exclusively. This is
+ useful, if you cannot determine any specific user and don't want to
+ build up a dummy policy granting default permissions.</p></li>
+</ul>
+
+</td></tr>
+
+<TR><TD BGCOLOR="#666699">
+ <H3><FONT COLOR="#ffffff" SIZE=4>
+ <a name="overview">Overview</a></FONT></H3>
+</TD></TR>
+<TR><TD>
+<p>
+<img src="../images/sec_overview.jpg">
+</p>
+</td></tr>
+
+<TR><TD BGCOLOR="#666699">
+ <H3><FONT COLOR="#ffffff" SIZE=4>
+ <a name="untrusted">Dealing with Untrusted Code</a></FONT></H3>
+</TD></TR>
+<TR><TD>
+Untrusted code should, in general, run in a sandbox, that is, a restricted environment.
+
+<p><a name="untrusted_native"><b>Untrusted Native Code</b></a><br>
+One cannot restrict native code modifying the current context, poke memory, thus influencing the security policy. I think this is not a goal.
+
+<p><a name="untrusted_scripted"><b>Untrusted Scripted Code</b></a><br>
+Sandboxed script code, for example, a basic script, has to be restricted in the
+way that the underlying engine disallows modifying the following current
+context's access-control properties, i.e., all of:</p>
+
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+access-control.*
+</pre></td></tr></table>
+
+<p>as well as disallowing a call on the ac's <code>doPrivileged()</code>.
+These actions are security violations and have to be signalled via a
+<code>SecurityException</code>.</p>
+
+<p>In addition, it has to be ensured that the script cannot raise components
+exchanging the ac of the component context. Therefore, the script engine has
+to proxy the service manager ensuring the ac property</p>
+
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+/singletons/com.sun.star.security.theAccessController
+</pre></td></tr></table>
+
+<p>is original, by doing security checks when
+<code>XSingleComponentFactory::createInstanceWithContext()</code> or
+<code> XSingleComponentFactory::createInstanceWithArgumentsAndContext()</code>
+is called.
+
+<p><a name="untrusted_java"><b>Untrusted Java Code</b></a><br>
+In general, the same applies for Java as for scripts. In addition, the UNO policy has to be plugged under the Java AccessController restricting calls to the Java API.
+For example, imagine that the untrusted Java code opens a file using the Java core API.
+The Java AccessController has to control this access relying on its Java policy in effect.</p>
+<p>Another problem with integrating the Java and C++/UNO access controllers are
+dynamic restrictions, which is not yet solved.</p>
+
+<p><a name="untrusted_remote"><b>Untrusted Inter-Process Code</b></a><br>
+
+A remote user (inter-process user) is assumed to be authenticated when connected.
+The server code must ensure separating different users; it is not necessary that the client code needs to be trusted in terms of dynamic restrictions as demanded for untrusted scripted code.
+But it has to be ensured that the server-side ac implementation is always used when restricting server-side access, such as when permission checks have to be performed process-locally.
+<p>
+<img src="../images/sec_interprocess.jpg">
+</p>
+</td></tr>
+
+<TR><TD BGCOLOR="#666699">
+ <H3><FONT COLOR="#ffffff" SIZE=4>
+ <a name="current_implementation">Current Implementation Details</a></FONT></H3>
+</TD></TR>
+<TR><TD>
+<p>
+Upon bootstrapping the UNO core system getting an initial
+<a href="uno_contexts.html#component_context">component context</a>, the ac implementation of <code>stoc/source/security</code> (<code>sec.dll</code>/ <code>libsec.so</code>) is installed as a singleton. This is most commonly done using some of cppuhelper's bootstrapping function, for example:
+<a href="../../cppuhelper/defaultBootstrap_InitialComponentContext.html"><code>defaultBootstrap_InitialComponentContext()</code></a>.
+You can specify some <a href="micro_deployment.html#Bootstrap_Arguments">bootstrap variables</a> mapping directly to the above mentioned AccessController mode:
+<ul>
+ <li><p><code>UNO_AC=("on" | "off" | "dynamic-only" | "single-user" |
+ "single-default-user")</code><br>
+ The general ac mode</p></li>
+ <li></p><code>UNO_AC_SERVICE=</code><em>service-name</em>
+ <code>[optional]</code><br>
+ This overrides ac singleton service name to be used</p></li>
+ <li><p><code>UNO_AC_SINGLEUSER=(<em>UserId</em>|<em><nothing></em>)
+ [optional]</code><br>
+ The initial context runs with this user id or with default policy.
+ In this case, the <code>UNO_AC</code> has to be set to
+ <code>"single-user"</code> or <code>"single-default-user"</code>.
+ </p></li>
+ <li><p><code>UNO_AC_USERCACHE_SIZE=<em>n</em></code><br>
+ This value maps to the component context entry
+ <code>/implementations/com.sun.star.security.comp.stoc.AccessController/user-cache-size</code>,
+ denoting the number of user permission sets to be cached before
+ calling the policy (lru cache).</p></li>
+ <li><p><code>UNO_AC_FILEPOLICY=<em>file-url</em></code><br>
+ This value maps to the component context entry
+ <code>/implementations/com.sun.star.security.comp.stoc.FilePolicy/file-name</code>
+ denoting the file URL to read the user permission sets from. The
+ file policy service implementation of
+ <code>stoc/source/security</code> is installed.</p></li>
+</ul>
+<p><a name="recurring_calls"><b>Recurring Calls</b></a></p>
+<p>When implementing an ac, there is a specific issue concerning
+bootstrapping of the ac singleton.
+The ac is (to be) used in every service implementation code and has to cope with the situation that it is called recursively.
+This can occur when the ac implementation initially raises the policy singleton object which checks permissions.</p>
+<p>A (possible) solution for this is to let recurring
+<code>checkPermission()</code> pass unchecked.
+This assumes that one knows implementation details of the underlying policy,
+but one generally don't feel well allowing unchecked permission grants, even
+for a short time.</p>
+<p>A better (safer) solution for this problem is that you shift the time a
+permission is checked.
+Any recurring <code>checkPermission()</code> call will be passed unchecked, but the permission and user context is saved for later execution (when everything is initialized).
+For a clearer distinction that an access violation occurred during bootstrapping of the ac, this violation should not be notified using an <code>AccessControlException</code>, but a different <code>RuntimeException</code>, such as, <code>DeploymentException</code> (yet to be specified) <!-- xxx todo -->.
+The only drawback of this solution is that an error notification is not sent as
+soon as possible.</p>
+<p>Marking a stack, one commonly uses thread-local storage (tls).
+When calling an unknown implementation (e.g., the policy singleton) a tls slot has to be marked, thus one can recognize a recursive call.
+When recognizing a recursive call, the demanded permission and calling user have to be queued, performing the check later and the call is passed.
+</p>
+<p><a name="performance_considerations"><b>Performance Considerations</b></a></p>
+<p>The ac implementation uses caching of user permission sets
+(<code>/services/com.sun.star.security.AccessController/cache-size</code>)
+for the reason that a permission description has to be parsed (e.g.,
+extracting port numbers).
+Parsing a permission is performed only once, so any ongoing permission check (when the chain of granted permissions is read) can be done once, then using the parsed permission description for checking. <!-- rh: Check that sense of last sentence is OK. -->
+</p>
+<p><a name="file_policy"><b>File Policy Implementation</b></a></p>
+<p>The file policy implementation of <code>stoc/source/security</code>
+(implementation name <code>com.sun.star.comp.stoc.FilePolicy</code> is a
+simple policy reading from policy files.</p>
+<p>The structure of those files is <!-- structure is -->very similar to those of
+<a href="http://java.sun.com/j2se/1.4/docs/guide/security/permissions.html">Java policy files</a>, e.g.:</p>
+
+<table width="100%" bgcolor="#ffffaa"><tr><td><pre>
+grant user "dbo" {
+permission com.sun.star.io.FilePermission
+ "file:///home/dbo/-", "read,write,execute,delete";
+};
+
+grant user "jbu" {
+permission com.sun.star.io.FilePermission
+ "file:///home/jbu/-", "read,write,execute,delete";
+};
+
+// permission granted to everyone
+grant {
+permission com.sun.star.io.FilePermission
+ "file:///tmp/-", "read,write,execute,delete";
+};
+</pre></td></tr></table>
+</td></tr>
+
+<TR><TD BGCOLOR="#666699">
+ <H3><FONT COLOR="#ffffff" SIZE=4>
+ <a name="todos">Things left to do...</a></FONT></H3>
+</TD></TR>
+<TR><TD>
+The following items are still on the to-do list:
+<ul>
+<li><p><b>[high priority]: </b><br>
+The main work left is reviewing all ac relevant code and inserting permission checks.
+In general, this concerns resource access, for example, file io and sockets.
+Memory and CPU resources cannot be limited effectively.
+More than the above described permission types may come, entering the API,
+ac, and policy implementation.</p>
+<p>It is commonly agreed that security checks are implemented on the component level (UNO available) rather than in the base libraries, such as, <code>sal</code>.
+Checking on component level is much more flexible, which may be needed to improve performance, but this may also lead to more forgotten checks.</p>
+<p>A list of all client code that has to be reviewed will be published
+<a href="../tasks/access_control_review.html">here</a>.
+If you find any ac relevant code that which needs be revisited, but you don't have cvs rights to do it, <a href="mailto:Daniel.Boelzle@sun.com">eMail me</a> so I can append it to the list and contact the module owners.
+</p></li>
+<li><p><b>[mid priority]: </b><br>
+At present, the current context is not inherited by child threads being raised, so the user credentials are not accessible by the ac. This has to be solved by introducing new thread C++/UNO thread classes doing this implicitly by copying the following properties:
+<ul>
+<li>access-control.user-credentials.*</li>
+<li>access-control.restriction (initially the parent thread's context)</li>
+</ul>
+</li>
+<li><p><b>[low priority]: </b><br>
+The current context is not transferred via the URP-UNO interprocess bridge. It has to be transferred by transferring the above properties with little lack of performance (i.e., configurable).
+</p></li>
+<li><p><b>[low priority]: </b><br>
+The Java ac has to be integrated with the C++/UNO ac to run <a href="#untrusted_java">untrusted Java code</a> using the core Java API.
+</p>
+</li>
+</ul>
+</td></tr>
+
+<tr><td bgcolor="#666699">
+<p align=left><font color="#ffffff"> Author: <a href="mailto:Daniel.Boelzle@sun.com">
+<font color="#ffffff">Daniel Bölzle</font></a><br>
+<i>Copyright 2002 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.</i></font></p></td>
+</tr>
+</table>
+</body>
+</html>
diff --git a/content/udk/common/man/concept/unointro.html b/content/udk/common/man/concept/unointro.html
new file mode 100644
index 0000000..5b67d3f
--- /dev/null
+++ b/content/udk/common/man/concept/unointro.html
@@ -0,0 +1,12 @@
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+"http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+ <meta http-equiv="refresh" content="3; URL=http://wiki.services.openoffice.org/wiki/Uno/Cpp/Tutorials/Introduction_to_Cpp_Uno" />
+ <meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+ <p class="Header">Redirecting....</p>
+</body>
+</html>
diff --git a/content/udk/common/man/draft/library_unloading.html b/content/udk/common/man/draft/library_unloading.html
new file mode 100644
index 0000000..0f668ef
--- /dev/null
+++ b/content/udk/common/man/draft/library_unloading.html
@@ -0,0 +1,14 @@
+<html>
+<head>
+<meta http-equiv="refresh" content="5; URL=http://udk.openoffice.org/common/man/spec/library_unloading.html">
+
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+<h2>The page has moved to</h2>
+<p><a
+href="http://udk.openoffice.org/common/man/spec/library_unloading.html">http://udk.openoffice.org/common/man/spec/library_unloading.html</a></p>
+<p> </p>
+<p> </p>
+</body>
+</html>
diff --git a/content/udk/common/man/draft/scripting/BindingUI.html b/content/udk/common/man/draft/scripting/BindingUI.html
new file mode 100644
index 0000000..1c43a2e
--- /dev/null
+++ b/content/udk/common/man/draft/scripting/BindingUI.html
@@ -0,0 +1,172 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+ <title>Binding & the Binding UI</title>
+
+ <meta http-equiv="Content-Type"
+ content="text/html; charset=iso-8859-1" />
+ <base
+ href="http://cdelab18.ireland/twiki/bin/view/Projectdocs/BindingUISpike" />
+</head>
+ <body bgcolor="#ffffff">
+
+<h2>Binding and the Binding UI</h2>
+
+<h3>Information about binding and the binding UI</h3>
+ <i><b> Loading of macros</b></i>
+<p> The loading of macros is done through a BasicManager (basic/source/basmgr/basmgr.cxx).
+Each document has a BasicManager associated with it, and the application
+has a BasicManager has well. Each BasicManager has a stream, which is the
+content of the macros from their context (i.e. application or document).
+Macros have their own URL within Star/OpenOffice.org which is of the form
+macro://<path>/<library>.<module>.<method>
+ </p>
+
+<p> <i><b>Populating Dialogs</b></i> </p>
+
+<p> For populating the dialogs, the SfxConfigGroupListBox_Impl
+ (sfx2/source/dialog/cfg.cxx) queries the application's
+ BasicManager for a list of macros and then queries every open
+ document's BasicManager for their associated macros. The SfxConfigGroupListBox_Impl
+builds up a list of macros, which it populates the dialog box
+with. </p>
+
+<p> <i><b>Assignment of Macros to Events</b></i> </p>
+
+<p> Assignment of a macro to an event is done by the
+AssignDeleteHdl_Impl in _SfxMacroTabPage (sfx2/source/dialog/macropg.cxx),
+when the "Assign" button is pressed, it deletes any already assign
+macros to the event. Then assigns the new macro to the event.
+An assignment is just an event id with a macro name attached to
+it. </p>
+
+<p> <i>Comments from Mathias Bauer in italics (and similar in the following
+sections).</i> </p>
+
+<p> <i> This is the "old" view. Our new API describes events by names, but
+the dialog still uses the old API, and there is some code that mediates
+ between both APIs. The configuration dialogs will be replaced completely
+later, so we didn't want to invest here. Forget about the event Ids. </i></p>
+
+<p> <i> The "real" assignment inside the document and the way this is stored
+ uses the com::sun::star::document::XEventSupplier and com::sun::star::document::XEventBroadcaster
+API where an office document supports the event supplier interface, that
+provides a container to bind events (described by a name) to a script (only
+ StarBasic in the current implementation). More about that see below. </i>
+ </p>
+
+<p><i><b>Execution of Macros</b></i></p>
+
+<p> The various document types, e.g. SwXTextDocument, are subclasses of the
+SfxBaseModel. When an event is generated, it gets passed (how?) to the Notify
+method of the SfxBaseModel. This does ??, and makes a call to postEventImpl,
+passing in an SfxEventHint. </p>
+
+<p><i> As already mentioned the SFX still contains a lot of code using the old
+API, so the document based events are still created as SfxEventHints by
+the SFX representation of the document, the subclass of SfxObjectShell.
+ The model object is a listener to this object, and so it gets notified
+(the SfxBroadcaster/SfxListener pair implementation is used for that). Then
+the model itself broadcasts the event, but now it uses the event name, not
+the Id it got from the SfxObjectShell as a part of the SfxEventHint. So every
+listener that is registered using the new, UNO based API (and not the C++
+class SfxListener) is notified also. </i></p>
+
+<p> <i>There is one special listener that always registers for event notifications.
+This listener makes a lookup in a table to find a macro that is bound to
+the event in question, and if it finds one, it calls the macro.</i> </p>
+
+<p> The postEvent_Impl gets the InterfaceContainer (::cppu::OInterfaceContainerHelper),
+and gets an InterfaceIterator (::cppu::OInterfaceIteratorHelper) from
+it. It then calls notifyEvent on each of the XEventListeners returned
+by the iterator. </p>
+<p><i>Exactly. This is the "real" event handling, take all the previous
+stuff as mutable implementation detail, because at the end it's not important
+how the model gets notified that an event wants to be notified!</i><br/>
+</p>
+<p> In various methods on the SfxObjectShell we see direct calls to
+the SfxApplication::NotifyEvent method with various SfxEventHints such
+as SFX_EVENT_LOADFINISHED (defined in svtools?) . Also seen in methods
+on SfxViewFrame. The SfxObjectShell source also shows a number of Broadcast
+calls. This is a method inherited from the SfxBroadcaster. Do these have
+some significance? </p>
+<p><i> Partly. Every document based events that is created inside an SFX
+ based document is broadcasted by calling SfxApplication::NotifyEvent.
+ This method uses SfxEventConfiguration::ExecuteEvent that did the whole
+job in SO5. "The whole job" means that it called both globally and document
+specific bound macros. In SO6/OOo we replaced the binding mechanism for
+documents by a new API as mentioned above. So this part of the "job" was
+removed from the SfxEventconfiguration, as you can see in the code: this
+method quits the job, if the document itself has a bound macro. This macro
+will be called by the process described above. The MacroTable of the document
+ is only used for the dialog (it is part of the mediating code mentioned
+above), not for the event binding evaluation. If the document has no
+specific binding, the method proceeds with global bindings. We still need
+this, because we don't have a global event broadcaster and configuration,
+so here we use the old MacroTable stored for the application. SfxApplication::NotifyEvent
+also uses the passed document to force it to a broadcast the event, and
+that's the way our model gets notified and triggers the notification of
+its own listeners as described above. But the SfxObjectShell does some
+more internal broadcasts that are only internal communications between
+the document and its views. So these "Broadcast" calls are not related
+to the configurable events.</i><br/>
+</p>
+<p> When the SfxApplication::NotifyEvent is called, the SfxEventHint
+is queried for the SfxObjectShell. If the shell is a document preview the
+method returns. Otherwise it makes a call to </p>
+<p><i> Previews don't have UI and events. They are just a view. We use
+a complete document to make a preview, so it's necessary to do some magic
+in the code.</i><br/>
+</p>
+<p> SfxEventConfiguration::ExecuteEvent. After this call the event is
+broadcast (either synchronously or asynchronously using the SfxEventAsyncer_Impl).
+ When ExecuteEvent is called on an SfxEventConfiguration, it returns
+if the doc is a preview. The next check I really don't understand, but
+it returns if that's the case. </p>
+<p><i>It's the check for a document binding as mentioned above, because
+bindings at the document are handled by the new API.</i><br/>
+</p>
+<p>Otherwise, it attempts to get the macro from the SfxEventConfiguration_Impl's
+macro table (SvxMacroTableDtor). If it finds the macro, then what
+happens depends on whether the macro is being called synchronously. If
+it is synchronous, then skip the next paragraph and it calls ExecuteMacro
+on the results of a static call to GetOrCreate on SfxMacroConfig, otherwise
+it creates a new SfxAsyncEvent_Impl. The SfxAsyncEvent_Impl contains
+a Notify method & a Timer to deal with the possibility that another
+StarBasic macro might be running (it waits until this is done). When the
+timer handler (TimeHdl via macro hackery) is called it gets from the
+ SfxApplication the SfxMacroConfig and calls ExecuteMacro. The ExecuteMacro
+method does some checking to ensure that the macro is a StarBasic macro,
+and sets up some args before calling Call. This is turn calls Call on an
+SbMethod. From there on we're in StarBasic-land! </p>
+<p><i><b>
+Problems coming from the discussion</b></i> </p>
+
+<ul>
+ <li>Binding UI uses a C++ API which is language dependant on StarBasic</li>
+ <li>Intermediary code between C++ API and UNO-based API for binding and
+ execution</li>
+ <li>No global broadcaster</li>
+</ul>
+<br/>
+
+<h3>Tasks to be completed by the scripting teams</h3>
+<b>(suggestions coming from discussion of "Binding and the Binding UI" on
+the dev@framework.openoffice.org started on the 17<sup>th</sup> of June
+2002</b>)<br/>
+
+<ol>
+ <li>finish the scripting API for calling, accessing scripts </li>
+ <li>script containers </li>
+ <li>storage - preference to access storage is through a URL like
+ macro://<path or doc>/<library>.<module>.<method></li>
+ <li>IDE interface </li>
+ <li>later implement prototypes </li>
+ <li> Specification for the Binding UI</li>
+ <li>UNO-Based Binding UI (With help from UI Team)</li>
+ <li>Throw out remaining C++ API code and replace with a UNO-based API
+ for binding and invocation</li>
+ <li>Implement a "global" broadcaster </li>
+</ol>
+</body>
+</html>
diff --git a/content/udk/common/man/draft/scripting/DesignDoc/index.html b/content/udk/common/man/draft/scripting/DesignDoc/index.html
new file mode 100644
index 0000000..d983bac
--- /dev/null
+++ b/content/udk/common/man/draft/scripting/DesignDoc/index.html
@@ -0,0 +1,453 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><html><head>
+
+ <meta http-equiv="Content-Type" content="text/html;CHARSET=iso-8859-1">
+ <!-- udk.openoffice.org --><title>Design Document</title>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head><body link="#6666cc" alink="#cc3333" bgcolor="#ffffff" marginwidth="0" marginheight="0" leftmargin="0" topmargin="0"><hr>
+ <basefont size="-1" face="Arial, Helvetica, sans-serif">
+<table border="0" cellspacing="8" cellpadding="5" width="100%">
+ <tbody>
+ <tr valign="top">
+ <td valign="top" width="100%" id="bodycol" bgcolor="#ffffff">
+
+ <h1 align="center">Language Independent Scripting Framework</h1>
+
+ <h2 align="center">Design Document - Last update: 16th August 2002</h2>
+ This document should only be read after having read the <a href="http://udk.openoffice.org/common/man/draft/scripting/ArchDoc.20020618.sxw">
+ Architecture Document</a>
+ . This document contains:<br>
+
+ <ul>
+ <li><a href="#Diagrams">Class & Object Interaction Diagrams</a></li><li><a href="#Binding">Binding storage sequence diagrams</a>
+ <br>
+ </li>
+
+ <li><a href="#OOIDE">OpenOffice - IDE Integration Interaction Diagrams</a>
+ <br>
+ </li>
+ <li><a href="#Proposed_file_structure_for_scripting">Proposed File
+ structure for scripting</a>
+ </li>
+ <li><a href="#Language-Specific__Logical_Script_names">Language-specific
+ & Logical ScriptNames</a>
+ </li>
+ <li><a href="#Deployment_DTD">DTD & sample XML for Deployment</a>
+ </li>
+ <li><a href="#DTD_for_Script_Registry">DTD & sample XML for
+Script Registry</a>
+ </li>
+ <li><a href="#deployinterface">Deployment Interfaces</a> </li><li><a href="#Storage">Script storage interfaces</a><br>
+ </li>
+
+ <li><a href="#IDLFiles">Links to the IDL Files</a>
+ </li>
+
+ </ul>
+ <br>
+
+ <hr>
+ <h3><a name="Diagrams"></a>
+ Class & Object Interaction Diagrams</h3>
+ <img src="BindingObject.png">
+ <br>
+ Binding Object Class Diagram(<a href="BindingObject.dia">source</a>
+ ). <br>
+
+ <hr><img src="BindingSequence.png">
+ <br>
+ Binding Object Interaction Diagram(<a href="BindingSequence.dia">
+ source</a>
+ ). <br>
+
+ <hr>
+ <br><img src="ScriptInvocation.png">
+ <br>
+ Script Invocation Interaction Diagram(<a href="ScriptInvocation.dia">
+ source</a>
+ ). <br>
+
+ <hr><img src="ScriptInvocationClassDiagram.gif">
+ <br>
+ Script Invocation Class Diagram(<a href="ScriptInvocationClassDiagram.dia">
+ source</a>
+ ). <br>
+
+ <hr><br>
+ <h3><a name="Binding"></a>Binding storage sequence diagrams</h3>
+ <h3><img src="BindingActions.png">
+
+ </h3>
+
+ Actions available on Bindings( <a href="BindingActions.dia">source</a>
+ ). <br>
+ XBinding represents a binding, this is an event (string) and
+script (string) pair. XBindingStore is the interface for access the
+binding storage of a certain document or the application. It provides
+store, remove and query functionality of binding objects implementing the
+XBinding interface. <br>
+
+ <hr><img src="BindingActions2.png">
+ <br>
+ Query available on Bindings(<a href="BindingActions2.dia">source</a>
+ ). <br>
+
+ <hr width="100%" size="2">
+ <h3><a name="OOIDE"></a>
+ OpenOffice - IDE Integration Interaction Diagrams</h3>
+ <img src="Source-Edit.png" alt="Editing a Script in an IDE" width="762" height="646">
+
+ <p> Editing a script in an IDE(<a href="Source-Edit.dia">source</a>
+ )</p>
+ Context:
+ <ul>
+ <li>all the GUI used for binding and parcel management is implemented
+ in OpenOffice and it is embedded into the IDE using the OpenOffice Bean</li>
+ <li>a temporary area of the filesystem is used to transfer files,
+ parcels selected by the user in the above OpenOffice GUI into the IDE
+(this should be transparent to the user)</li>
+
+ </ul>
+ When a file is selected to be edited or a new file is created roughly
+ the dialog taking place is: - OpenOffice checks if the IDE is running,
+if not it starts it<br>
+
+ <ul>
+ <li> OpenOffice moves the selected content (from the document)
+into the temporary area and notifies the IDE that the content is there</li>
+ <li> the IDE loads the content from the temporary area</li>
+ <li>user edits, saves (maybe builds)</li>
+ <li>at save the IDE notifies OpenOffice that the content is again
+ available in the temporary area </li>
+ <li> OpenOffice (C&C module) moves the content back into the
+document</li>
+
+ </ul>
+ Transferred content will most likely have to be a complete build environment
+ rather than one file only. Transfer can be optimized to transfer only changed
+ files rather than all the files. When a file is displayed all the corresponding
+ build environment has to be transferred to facilitate build, run and debug.<br>
+ <br>
+
+ <hr width="100%" size="2"><img src="SO-IDE-debug.png" alt="Debugging a OpenOffice Script in an IDE" width="959" height="668">
+ <br>
+ <br>
+ Debugging a script in an IDE(<a href="SO-IDE-debug.dia">source</a>
+ )<br>
+ <br>
+ This diagram describes how OpenOffice and the IDE interact to facilitate
+debugging. When the user starts up the IDE the debugging connection (e.g.
+debugger from IDE attaching to the OpenOffice JVM) should be established.
+This is the time to check whether individual runtimes or OpenOffice have
+to be restarted in order to facilitate debugging from the IDE.<br>
+ <br>
+ The dialog protocol is this:
+ <ol>
+ <li>OpenOffice tries to start the IDE</li>
+ <li>OpenOffice checks whether the runtime is running and is debug
+enabled (if not then the runtime or OpenOffice has to be restarted</li>
+ <li>OpenOffice starts the IDE </li>
+ <li>when IDE signals that it is ready OpenOffice sends the parameters
+needed for debugger attachment (host, port etc) </li>
+ <li>the user sets breakpoints in the IDE </li>
+ <li>at this point the user will invoke the script, this will be
+either from the IDE or from OpenOffice; if it is from the IDE then the IDE
+has to request an invocation from OpenOffice, if it is from OpenOffice then
+nothing has to be done (a user action will invoke the script)</li>
+ <li>after invocation the runtime will pause waiting for the debugger
+(from the IDE) to attach, a message has to be sent to the IDE to start the
+debugger</li>
+ <li>the IDE debugger will attach to the runtime in OpenOffice </li>
+
+ </ol>
+ This protocol is somewhat Java specific, it might need changes for other
+runtimes.<br>
+ <br>
+
+ <hr width="100%" size="2"><br>
+ <img src="Exception-IDE.png" alt="Debugging Exceptions from OpenOffice in an IDE" width="1110" height="805">
+ <br>
+ <br>
+ Debugging a script exception in an IDE(<a href="Exception-IDE.dia">source</a>
+ )<br>
+ <br>
+ Exception handling is a variation of the code editing and debug enabling
+diagrams. The diagram describes the dialog between OpenOffice and the IDE
+when the IDE has not been started yet so the attachment to the OpenOffice
+ JVM from the IDE has to be done. <br>
+ <br>
+ The dialog is the following:
+ <ol>
+ <li>after invocation of a script when an exception is caught by
+the script runtime check if the IDE is already running, if not and OpenOffice
+is not running with debugger attachment enabled to the JVM then OpenOffice
+has to be restarted</li>
+ <li>if OpenOffice has been restarted then it is the user's responsibility
+to get the script invoked again</li>
+ <li>if the IDE was not running then it is started and the source
+is loaded as described in the Edit diagram</li>
+ <li>after this the debugger from the IDE attaches to the OpenOffice
+JVM as described in the debug enabling diagram</li>
+ <li>the user can evaluate variables at this point</li>
+ <li>changing and saving the code at this point happens as already
+described in the Edit diagram</li>
+
+ </ol>
+ <br>
+
+ <hr>
+ <h3><a name="Proposed_file_structure_for_scripting"></a>
+ Proposed file structure for scripting</h3>
+ The file structure for the application and the document will be
+the same, the only difference is the structure for the document will stored
+ in the document zip file. The file structure is as follows
+
+ <pre>scripting/<br> |<br> +- java/<br> |<br> +- basic/<br> |<br> +- otherLanguage/<br></pre>
+ under the language specific folder
+ each script parcel has a separate
+folder. The file and folder structure in a script parcel is arbitrary, it
+depends on how the developer organizes files and folders of
+ the parcel. <br>
+ <br>
+A registry file exists at the script level in the directory structure
+ that identifies the scripts that are installed (in either the document
+ or application) or other metadata associated with the script.
+
+ <hr><br>
+
+ <h3><a name="Language-Specific__Logical_Script_names"></a>
+ Language-Specific & Logical Script names</h3>
+ <u>Generic script name:</u><br>
+ script://<sname>/[<qtype>['?'<query>]]<br>
+ <br>
+ ; name of a script functionality<br>
+ sname =: <name><br>
+ ; query type<br>
+ qtype =: <name><br>
+ ; query<br>
+ query =: <qelm>(','<qelm>)*<br>
+ ; query element<br>
+ qelm =: <word>'='<name><br>
+ <br>
+ <br>
+ <u>Language specific script name:</u><br>
+ script:///<lname>'?'<lpart><br>
+ <br>
+ ; language runtime name<br>
+ lname =: <name><br>
+ ; language specific portion of name<br>
+ lpart =: sequence of any printable characters<br>
+ <br>
+ <br>
+ name =: <word>('.'<word>)*<br>
+ word =: <alpha>(['-'|'_'](<alpha>|<digit>))*<br>
+ alpha =: an alphabetical character as in rfc2396-1.6<br>
+ digit =: a digit character as in rfc2396-1.6<br>
+
+ <hr width="100%" size="2">
+ <h3><a name="Deployment_DTD"></a>
+ Deployment DTD</h3>
+ <?xml version="1.0" encoding="UTF-8"?> <br>
+ <!ELEMENT script (logicalname, languagename, dependencies, description?,
+ delivery)><br>
+ <!ELEMENT bundle (script+)><br>
+ <!ELEMENT logicalname EMPTY><br>
+ <!ELEMENT languagename EMPTY><br>
+ <!ELEMENT dependencies (dependfile+)><br>
+ <!ELEMENT description (#PCDATA)><br>
+ <!ELEMENT delivery (deliverfile+)><br>
+ <!ELEMENT deliverfile EMPTY><br>
+ <!ELEMENT dependfile EMPTY><br>
+ <!ATTLIST script<br>
+ language CDATA #REQUIRED<br>
+ deploymentdir CDATA #REQUIRED<br>
+ ><br>
+ <!ATTLIST logicalname<br>
+ value CDATA #REQUIRED<br>
+ ><br>
+ <!ATTLIST languagename<br>
+ value CDATA #REQUIRED<br>
+ location CDATA #REQUIRED<br>
+ ><br>
+ <!ATTLIST dependfile<br>
+ name CDATA #REQUIRED<br>
+ isdeliverable (yes | no) #REQUIRED<br>
+ ><br>
+ <!ATTLIST deliverfile<br>
+ name CDATA #REQUIRED<br>
+ type (binary | data | source | resource) #REQUIRED<br>
+ ><br>
+ <br>
+
+ <h3>Sample deployment XML</h3>
+ <?xml version="1.0" encoding="UTF-8"?><br>
+ <!DOCTYPE bundle SYSTEM "deployment.dtd"><br>
+ <bundle><br>
+ <script language="Java" deploymentdir="calc.convert.EuroConvert"><br>
+ <logicalname value="calc.convert.EuroConvert"/><br>
+ <languagename value="com.sun.star.calc.EuroConvert"<br>
+ location="convert.jar"/><br>
+ <dependencies><br>
+ <dependfile name="data/currenices.txt" isdeliverable="yes"/><br>
+ </dependencies><br>
+ <delivery><br>
+ <deliverfile name="convert.jar" type="binary"/><br>
+ <deliverfile name="currencies.txt" type="resource"/><br>
+ </delivery><br>
+ </script><br>
+ </bundle><br>
+
+ <hr>
+ <h3><a name="DTD_for_Script_Registry"></a>
+ DTD for Script Registry</h3>
+ <?xml version="1.0" encoding="UTF-8"?> <br>
+ <!ELEMENT script (logicalname, languagename, description, properties,<br>
+ dependencies)><br>
+ <!ELEMENT logicalname EMPTY><br>
+ <!ELEMENT languagename EMPTY><br>
+ <!ELEMENT description (#PCDATA)><br>
+ <!ELEMENT properties (#PCDATA)><br>
+ <!ELEMENT dependencies (file)><br>
+ <!ELEMENT file EMPTY><br>
+ <!ATTLIST script<br>
+ language CDATA #REQUIRED<br>
+ rootdir CDATA #REQUIRED<br>
+ ><br>
+ <!ATTLIST logicalname<br>
+ value CDATA #REQUIRED<br>
+ ><br>
+ <!ATTLIST languagename<br>
+ value CDATA #REQUIRED<br>
+ location CDATA #REQUIRED<br>
+ ><br>
+ <!ATTLIST file<br>
+ name CDATA #REQUIRED<br>
+ ><br>
+
+ <h3>Sample XML for Script Registry</h3>
+ <?xml version="1.0" encoding="UTF-8"?><br>
+ <!DOCTYPE script SYSTEM "registry.dtd"><br>
+ <script language="Java" rootdir="calc.convert.EuroConvert"><br>
+ <logicalname value="calc.convert.EuroConvert"/><br>
+ <languagename value="com.sun.star.calc.EuroConvert"<br>
+ location="convert.jar"/><br>
+ <description>A Euro Converter</description><br>
+ <properties>Other properties</properties><br>
+ <dependencies><br>
+ <file name="data/currencies.txt"/><br>
+ </dependencies><br>
+ </script><br>
+
+ <hr width="100%" size="2">
+ <h3><a name="deployinterface"></a>
+ Deployment Interfaces</h3>
+ <a href="XParcel.idl">XParcel</a>
+ Interface access to a parcel file hierarchy by retrieving the hierarchy
+ and adding/removing content (using w3c standard urls with wildcards in them
+ to add/remove a number of files/folders). The parcel name can also be retrieved.
+The interface XParcel is implemented by the Parcel service.<br>
+ <br>
+ <a href="XParcelStore.idl"> XParcelStore</a>
+ provides access to parcels installed into a document or the application
+context. Complete parcel packages (archived as zip) can be installed. Parcels
+can be created (to fill with content through the XParcel interface) and parcels
+can be removed. A list of all the installed parcels can also be obtained.<br>
+ <br>
+
+
+ <hr>
+ <h3><a name="Storage"></a>Script storage interfaces</h3>
+
+ The toplevel storage service is ScriptingStorage. Every document and
+the application has one ScriptingStorage component that provides access to
+the scripts stored in that context. ScriptingStorage implements several interfaces:<br>
+ <br>
+ <ul>
+ <li>XScriptAccessManager: provides access to script related data encapsulated in the ScriptInfo component</li>
+ <li>XScriptImplAccess: resolves logical script names to language specific script names</li>
+ <li>XNamingAccess: provide access to the logical naming of scripts
+(it is designed to provide various views, a hierarchical one will be implemented)</li>
+ <li>XBindingStore: provide access to the binding storage (described above)</li>
+ <li>XParcelStore: provide access to the parcel storage (described above)</li>
+ </ul>
+ScriptInfo is a service providing access to information related to one script. It contains two interfaces:<br>
+ <ul>
+ <li>XScriptInfo: provides access to script metadata</li>
+ <li>XScriptStore: provides support for implementation of data persistence by the script<br>
+ </li>
+ </ul>
+
+<hr>
+ <h3><a name="IDLFiles"></a>
+ IDL Files</h3>
+ The following are the proposed
+ interfaces. In some cases, these are just placeholders and need further
+ work.
+
+ <p><a href="CannotResolveScriptNameException.idl">CannotResolveScriptNameException.idl</a>
+ <br>
+ <a href="ScriptInfoAccessException.idl">ScriptInfoAccessException.idl</a>
+ <br>
+ <a href="ScriptRuntime.idl">ScriptRuntime.idl</a>
+ <br>
+ <a href="ScriptRuntimeException.idl">ScriptRuntimeException.idl</a>
+ <br>
+ <a href="ScriptRuntimeManager.idl">ScriptRuntimeManager.idl</a>
+ <br>
+ <a href="ScriptStorage.idl">ScriptStorage.idl</a>
+ <br>
+ <a href="XBinding.idl">XBinding.idl</a>
+ <br>
+ <a href="XBindingStore.idl">XBindingStore.idl</a>
+ <br>
+ <a href="XFunction.idl">XFunction.idl</a>
+ <br>
+ <a href="XFunctionProvider.idl">XFunctionProvider.idl</a>
+ <br>
+ <a href="XNameNode.idl">XNameNode.idl</a>
+ <br>
+ <a href="XScriptAccessManager.idl">XNamingAccess.idl<br>
+ </a>
+ <a href="XParcel.idl">XParcel.idl<br>
+ XParcelStore.idl<br>
+ </a>
+ <a href="XScriptAccessManager.idl"> XScriptAccessManager.idl
+ </a>
+ <br>
+ <a href="XScriptContext.idl">XScriptContext.idl</a>
+ <br>
+ <a href="XScriptImplAccess.idl">XScriptImplAccess.idl</a>
+ <br>
+ <a href="XScriptInvocation.idl">XScriptInvocation.idl</a>
+ <br>
+ <a href="XScriptStore.idl">XScriptStore.idl</a>
+ <br>
+ <a href="XScriptURI.idl">XScriptURI.idl</a>
+ <br>
+ <a href="ScriptURI.idl">ScriptURI.idl</a>
+ <br>
+ <a href="XScriptNameResolver.idl">XScriptNameResolver.idl</a> <br>
+<a href="XScriptStore.idl">XScriptInfo.idl<br>
+XScriptStore.idl</a> <br>
+ <a href="ScriptInfo.idl">ScriptInfo.idl</a><br>
+ <a href="Parcel.idl">Parcel.idl</a>
+ <br>
+ </p>
+
+ <b><br>
+ <br>
+ </b><br>
+ </td>
+ </tr>
+
+ </tbody>
+</table>
+ <!-- end footer --><br>
+ <br>
+ <br>
+ <br>
+ <br>
+ <br>
+
+<br>
+<br>
+</body></html>
diff --git a/content/udk/common/man/draft/scripting/ProblemsIssues.html b/content/udk/common/man/draft/scripting/ProblemsIssues.html
new file mode 100644
index 0000000..da13401
--- /dev/null
+++ b/content/udk/common/man/draft/scripting/ProblemsIssues.html
@@ -0,0 +1,216 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+ <title>Framework Problem & Issues</title>
+
+ <meta http-equiv="content-type"
+ content="text/html; charset=ISO-8859-1">
+</head>
+ <body>
+
+<h1>Scripting Framework Problem Areas & High-Level Issues</h1>
+
+<h2>Runtime Container</h2>
+ <u> Problem Statement: </u><br>
+ Scripts are executed within a language specific script runtime. We need
+to define the features of this runtime container and the contract between
+the container and the scripts run in it, with regard to threading, symbol
+resolution and persistence of script related data. <br>
+ <br>
+ <u>Requirements:</u> <br>
+
+<ul>
+ <li>define the contract between the script container and a script, this
+contract should be language neutral </li>
+ <li>define the threading model that script containers should use</li>
+ <li>define how symbols are resolved within the script container</li>
+ <li>define how symbols conflicts are handled</li>
+ <li>define the services the container provides to the script for saving
+state</li>
+
+</ul>
+ <u>Issues: </u><br>
+
+<ul>
+ <li>the requirement for language neutrality will impose restrictions on
+ how the contract between the script runtime container and scripts run
+ in the container can be defined</li>
+ <li>it would be impossible evaluate our contract against all scripting
+languages, so we must select a subset of languages to use </li>
+
+</ul>
+<u>Further analysis:</u><br>
+<ul>
+ <li><a href="thread-management.html">Thread management</a></li>
+ <li><a href="persistence.html">Persistence of script data</a></li>
+ <li><a href="symbol-resolution.html">Symbol/Dependency Resolution</a></li>
+</ul>
+
+<h2>Code Management</h2>
+ <u>Problem Statement:</u> <br>
+ Scripts can be in many formats, source or binary, encrypted or obfuscated.
+ They can be stored in many locations, eg. a filesystem or a webserver.
+They can be stored as files, or embedded within a file. They can be protected
+ by security features such as digital signing. <br>
+ Clients of the scripting framework (eg. StarOffice, IDEs) need to be able
+ to access these scripts without concerning themselves with where and how
+the scripts are stored. The Application Scripting Framework needs to provide
+ a set of services and interfaces which will allow these clients such access.
+ <br>
+ <br>
+ <u>Requirements:</u> <br>
+
+<ul>
+ <li>research current StarOffice script location/load/store interfaces</li>
+ <li>define the digital signing service for scripts</li>
+ <li>define the script location service</li>
+ <li>define the script loading/storing service </li>
+
+</ul>
+<u>Further analysis:</u><br>
+<ul>
+ <li><a href="code-management.html">Code management</a><br>
+ </li>
+</ul>
+
+<h2>IDE related Issues </h2>
+
+<ul>
+ <li>Do we want a scripting IDE as part of SO (I will call this internal
+ IDE for simplicity) or an external one plugging into SO? One option could
+be to have an internal IDE for StarBasic and an external IDE for the new
+scripting languages. The external editor should be NetBeans (Forte for JAVA?).
+NetBeans already has some support for BeanShell, Dynamic Java and Jython.
+This support definitely needs further improvements. If we go with NetBeans
+then we might need to cooperate with NetBeans developers. NetBeans has a
+framework for plugging in new scripting interpreters into the IDE. </li>
+ <li>The main issues are debugging and editing scripts, code browsing,
+ configuration.</li>
+ <li>We need possibilities to edit and debug scripts from simple command
+line applications. </li>
+
+</ul>
+ <u>Code editing:</u><br>
+ We need the script storage and script loading and storing interfaces
+as described above. This needs to be able to retrieve and store a script
+source and its context (document, application). Both the IDE (internal and
+external) and the command line application need to use these interfaces to
+edit scripts and their contexts. <br>
+ NetBeans has an API that abstracts storage of files and file like objects.
+ This could use the script loading and storing interfaces to edit scripts.
+Context editing could be done with Nodes, the DataSystems API and the Explorer
+API, but this needs to be investigated. <br>
+ <u>Debugging:</u><br>
+ Main issues are launching, setting breakpoints and evaluating variables.
+ <br>
+ The IDE has to be able to launch the language specific debugger/interpreter
+ and load the binary/script source and its context in it, an interface has
+to be defined for this. <br>
+ OpenOffice already has an <a
+ href="http://api.openoffice.org/common/ref/com/sun/star/script/XDebugging.html">interface</a>
+for setting/clearing breakpoints and evaluating variables. This could be
+the interface the debugger/interpreter plug-in of a new language will have
+to implement. An IDE will have to use this interface to implement the debugging
+tasks and implement a Watch and Output windows to display various information.
+ <br>
+ (If we go with NetBeans) the JVM and NetBeans are already integrated and
+ they do not use this interface so without a language agnostic framework
+most of the work would be done. If we want a language agnostic framework
+we will have to add extra implementation for languages not supported by NetBeans.
+This would be different from the way the JVM is integrated.<br>
+ If we go with one or more Java based scripting language(s) as part of our
+ implementation then we need to investigate ways of translating script code
+ line numbers to Java code line numbers and script variables to underlying
+Java variables. Command line debugging does not need much here, the user
+will have to launch the language specific debugger and configure it (to
+find the SO libraries). A command line utility will need to be developed
+that will load the script in the debugger/interpreter and make it aware
+of the script context. <br>
+ <u>Code browsing:</u><br>
+ This is not as important as the previous ones. <br>
+ We need an interface that would return object and method names from a script.
+ This will need language specific implementations. The IDE will have to
+use this to display and navigate through the code structure. <br>
+ There would be no command line functionality here.<br>
+ <u>Configuration</u>:<br>
+ This has already been described as "runtime-related user interfaces". We
+ need a way to provide similar functionality when debugging from the command
+ line. <br><br>
+<u>Further analysis:</u><br>
+<ul>
+ <li><a href="ide.txt">IDE requirements</a><br>
+ </li>
+</ul>
+
+<h2>Macro Recording</h2>
+ Macro recording is not a very big issue in the investigation phase. The
+main issue is whether we can generate macros made of UNO API calls or we
+have to stay with the dispatch APIs. The investigation should be about
+whether this is possible or not and how to do it. It is very simple to
+write macro recorders for any language if the recorded macros use the dispatch
+API. Considering that for UNO API based macro recording we would probably
+have to write UNO API based macros for all the dispatch calls in all the
+languages that we support, UNO API based macro recording might not be feasible.
+But this should be the subject of the investigation. <br>
+
+<h2>Runtime related security</h2>
+ <u>Problem domain definition:</u><br>
+ The language runtime security subsystem is a set of restrictions which
+are applied by the language runtime to a script during loading and execution.
+ <br>
+ Restrictions could be applied to:<br>
+
+<ul>
+ <li>the type of the script</li>
+ <li>the source of the script</li>
+ <li>the length of life of the script</li>
+ <li>the amount of resource available to the script</li>
+ <li>the availability of a service by the type of the service</li>
+ <li>the availability of the specific service by the type of the
+request</li>
+ <li>the availability of the specific service by the content of the request</li>
+
+</ul>
+ <u>Participants:</u><br>
+
+<ul>
+ <li>the script execution sandbox<br>
+ an implementation of the language neutral runtime security subsystem</li>
+ <li>the language runtime (the runtime container) <br>
+ language specific binding to the execution engine (VM)</li>
+ <li>the language execution context<br>
+ static and runtime data available to a script during execution</li>
+ <li>the code management subsystem<br>
+ script finder/explorer/loader</li>
+ <li>UI of security configuration</li>
+ <li>debugger </li>
+
+</ul>
+
+<h2>Script lifecycle services</h2>
+ <u>Problem domain definition:</u><br>
+ The script lifecycle services is a subsystem of the execution engine (VM)
+which is responsible for:<br>
+
+<ul>
+ <li>creation and maintains of the script execution context</li>
+ <li>control over the script length of life</li>
+ <li>accounting of the script acquired resources</li>
+ <li>clean up after the script end of life. </li>
+
+</ul>
+ <u>Participants:</u><br>
+
+<ul>
+ <li>the code management subsystem <br>
+ script finder/explorer/loader</li>
+ <li>the language runtime (the runtime container)<br>
+ language specific binding to the execution engine (VM)</li>
+ <li>the language execution context <br>
+ static and runtime data available to a script during execution
+ </li>
+
+</ul>
+ <br>
+</body>
+</html>
diff --git a/content/udk/common/man/draft/scripting/Services-and-interfaces.html b/content/udk/common/man/draft/scripting/Services-and-interfaces.html
new file mode 100644
index 0000000..d2f3895
--- /dev/null
+++ b/content/udk/common/man/draft/scripting/Services-and-interfaces.html
@@ -0,0 +1,78 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+ <title>Scripting Framework Services & Interfaces</title>
+
+ <meta http-equiv="content-type"
+ content="text/html; charset=ISO-8859-1">
+</head>
+ <body>
+ Below are the core services and interfaces which we think are required.
+<br>
+ <br>
+ Services with required supported interfaces:
+<ul>
+ <li><a href="ScriptManager.idl">ScriptManager</a> service</li>
+
+ <ul>
+ <li>XModules</li>
+ <li>XBind</li>
+ <li>XScriptManager</li>
+
+ </ul>
+ <li><a href="ScriptEngine.idl">ScriptEngine</a> service</li>
+
+ <ul>
+ <li>XModules</li>
+ <li>XBind</li>
+ <li>XScriptEngine </li>
+
+ </ul>
+ <li><a href="ScriptMethod.idl">ScriptMethod</a> service</li>
+
+ <ul>
+ <li>XMethod <br>
+ </li>
+
+ </ul>
+
+</ul>
+ Set of interfaces:<br>
+
+<ul>
+ <li><a href="Xbind.idl">XBind</a></li>
+ <li><a href="XMethod.idl">XMethod</a></li>
+ <li><a href="XModules.idl">XModules</a></li>
+ <li><a href="XScriptEngine.idl">XScriptEngine</a></li>
+ <li><a href="XScriptManager.idl">XScriptManager</a><br>
+ </li>
+
+</ul>
+ A ScriptManager service manages registered ScriptEngine services. It aggregates
+the modules and bind functionality of the ScriptEngine services. <br>
+ A ScriptEngine service represents a script engine for a particular language.
+ <br>
+ A ScriptMethod service represents a script method for a particular language
+that may be invoked by StarOffice. <br>
+ <br>
+ The XBind interface provides methods to bind and unbind a method, which
+is also associated with a particular context, application or document. A bind
+will create a ScriptMethod service. <br>
+ <br>
+ The XMethod interface provides a method to invoke a script method synchronously
+on a method written in a script language. <br>
+ <br>
+ The XModules interface provides methods to obtain the set of available libraries,
+modules and methods or to check that methods exists. Module/Library/Method
+information may be represented as structs. No hierarchy traversal is required
+to obtain the information. Hierarchy is implicit in the library/module/method
+name space. Can be similar in style to the functionality of java.lang.ClassLoader
+to obtain packages etc. <br>
+ <br>
+ The XScriptEngine interface provides methods to initiate, query, and monitor
+a script engine. <br>
+ <br>
+ The XScriptManager interface provides methods to register/deregister ScriptEngine
+services. <br>
+</body>
+</html>
diff --git a/content/udk/common/man/draft/scripting/ThreadingSoln.html b/content/udk/common/man/draft/scripting/ThreadingSoln.html
new file mode 100644
index 0000000..303b77d
--- /dev/null
+++ b/content/udk/common/man/draft/scripting/ThreadingSoln.html
@@ -0,0 +1,265 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+ <title>Threading Solution</title>
+
+
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+
+<h2>Introduction</h2>
+ The goals of the threading solution research are: <br>
+
+<ul>
+ <li>To establish how threading currently works in OpenOffice</li>
+ <li>To investigate issues related to running multiple scripts simultaneously
+in OpenOffice</li>
+ <li>To suggest how IDEs would be able to attach to OpenOffice scripts
+ <br>
+ </li>
+
+</ul>
+
+<p> <a name="contents"></a> </p>
+
+<h2>Contents</h2>
+
+<ul>
+ <li><a href="#current_behaviour">Current Star Basic script threading behaviour</a>
+ </li>
+ <li><a href="#current_win_behaviour">Current Ms Basic script threading
+behaviour</a> </li>
+ <li><a href="#event_handling">Event Handling</a> </li>
+ <li><a href="#options">Options for script threading behaviour</a> </li>
+ <li><a href="#issues">Issues with allowing one script per document</a>
+ </li>
+ <li><a href="#configuration">Configuration of threading behaviour</a>
+ </li>
+ <li><a href="#ide">Identifying script threads in a debugger</a> </li>
+ <li><a href="#solarmutex">SolarMutex</a> </li>
+
+</ul>
+ Also of interest are these initial thoughts on the thread management topic
+posted to <a
+ href="http://udk.openoffice.org/common/man/draft/scripting/thread-management.html">openoffice.org</a>
+
+<hr> <a name="current_behaviour"></a>
+<h3>Current StarBasic script threading behaviour</h3>
+
+<p> Run the macro from the "Macro" dialogbox. </p>
+
+<ul>
+ <li>No frozen document you can work on any documents </li>
+ <li>Macro running in background </li>
+ <li>No macro can be run </li>
+
+</ul>
+ Assign the macro to the "F10" key. Press that key.
+<ul>
+ <li>Active document is frozen </li>
+ <li>Other document are not frozen </li>
+ <li>Can't run any macro on other document while the macro is still running
+even from the "Macro" dialogbox. </li>
+
+</ul>
+ While the macro is running, if you open the "Macro" dialogbox, the macro
+is paused
+<ul>
+ <li>If you close the dialog box, the macro is resumed </li>
+ <li>If you decide to edit a macro, the macro is resumed and you can stop
+the macro from the BASIC editor </li>
+ <li>If you switch to the BASIC editor and click on the stop button, the
+macro will be stop but nothing in the UI will be updated until the "Macro"
+dialogbox is closed (this seems to be a bug). </li>
+
+</ul>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <a name="current_win_behaviour"></a>
+<h3>Current Ms Basic script threading behaviour</h3>
+
+<p> Run the macro from the "Macro" dialogbox. </p>
+
+<ul>
+ <li>All document are frozen </li>
+
+</ul>
+ Run the macro from the Ms Visual Basic editor.
+<ul>
+ <li>All document are frozen </li>
+
+</ul>
+ Assign the macro to the "F10" key. Press that key.
+<ul>
+ <li>All document are frozen </li>
+
+</ul>
+ Run a macro that will access Excel and change the cell values.
+<ul>
+ <li>All word document are frozen </li>
+ <li>Excel is not frozen, macro is running and changing value and you can
+change values. </li>
+
+</ul>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <a name="event_handling"></a>
+<h3>Event Handling</h3>
+
+<p> The OpenOffice process has multiple threads. Any thread that calls Application::Yield
+or Application::Reschedule dispatches GUI events. Dispatching GUI events requires
+the SolarMutex, so only one thread at a time can dispatch GUI events. In
+practice the "main" OpenOffice thread is the thread that dispatches most GUI
+events. </p>
+
+<p> Events can be either synchronous or asynchronous. </p>
+
+<p> Synchronous events are handled immediately, that means that the functionality
+bound to the event is invoked immediately from the call stack of the thread
+where the event occurred. The thread is therefore blocked until the event has
+been handled. </p>
+
+<p> Asynchronous events are placed in a message queue by the thread handling
+the event, and the thread is not blocked, it continues executing. The message
+queue is serviced by any thread which calls Application::Yield or Application::Reschedule.
+ </p>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <a name="options"></a>
+<h3>Options for script threading behaviour</h3>
+
+<p> There are two possible threading models that we could use: </p>
+
+<ol>
+ <li>One script per OpenOffice process - this is the threading model currently
+used by OpenOffice. </li>
+ <li>One script per OpenOffice document - this would allow more than one
+script to be run at the same time, but only one script could be run per document
+at a time. The thread running the script would have to grab a document lock
+before invoking the script and release it when the script has completed.
+ </li>
+
+</ol>
+
+<p> The best solution is to implement option 2, and add the possibility to
+configure the threading behaviour so that it acts like option 1 if the user
+wishes to use this behaviour (see Configuration section below). </p>
+
+<p> So, how do we implement option 2? From discussions with Mathias Bauer
+and Joerg Budischweski they feel that OpenOffice should manage the spawning
+of the threads which would invoke the scripts. In the case of synchronous
+events the thread handling the event would spawn a thread in which it would
+then invoke the script. In the case of asynchronous threads the thread which
+had grabbed the event off the message queue would spawn a new thread when
+it wanted to invoke a script. In other words the responsibility for managing
+the per document script threads would lie with OpenOffice, not the scripting
+framework. </p>
+
+<p> Changes needed: </p>
+
+<ul>
+ <li>The thread calling XFunction.invoke() (main thread for synchronous
+ events, message queue thread for asynchronous events) needs to spawn a
+new thread and call XFunction.invoke() from there. </li>
+ <li>The document for which the XFunction is being invoked needs to be
+ locked for the duration of XFunction.invoke() (with a documentmutex of
+some sort) so other XFunctions cannot be invoked for that document. The most
+difficult thing is that also every view that tries to modify a document must
+stick to this rule </li>
+
+</ul>
+
+<p>See also: "Threading model for an office scripting framework" discussion
+on openoffice.udk.dev newsgroup </p>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <a name="issues"></a>
+<h3>Issues with allowing one script per document</h3>
+
+<p> Because of problems with thread safety in the OpenOffice API it is currently
+unsafe to allow more than one thread to make API calls at the same time. For
+this reason there is a global SolarMutex which thread unsafe API implementations
+automatically lock before executing any functionality, and unlock before returning.
+The thread calling the OpenOffice API is not aware of this SolarMutex. While
+the SolarMutex is grabbed, OpenOffice API calls from other threads will block
+until the SolarMutex becomes free. The OpenOffice UI will be frozen while
+the SolarMutex is locked. If a script calls a OpenOffice API, the solarmutex
+will be grabbed until the API call returns which would temporarily freeze
+all document windows. These freezes may be an unacceptable annoyance to users
+and they may prefer that the UI be completely frozen for the duration of
+script execution rather than having it freeze unexpectedly. </p>
+
+<p> See also: "Office API and thread safety" discussion on openoffice.framework.dev
+newsgroup </p>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <a name="configuration"></a>
+<h3>Configuration of threading behaviour</h3>
+
+<p> The threading behaviour of Office should be configurable so that the user
+can switch on/off the one script per document behaviour as they wish. A radio
+box should be added to the Scripting pane of the Office options dialog with
+the options: </p>
+
+<p> Allow only one script to be run by OpenOffice at a time. <br>
+ Allow one script per document to be run by OpenOffice at a time </p>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <a name="ide"></a>
+<h3>Identifying script threads in a debugger</h3>
+
+<p> The issue here is how we can identify which thread in a OpenOffice process
+is running the script we are interested in debugging. This is possible in
+java using the java.lang.Thread.setName() method. The pairing of script name
+and document name should be sufficient to uniquely identify the appropriate
+thread. </p>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <a name="solarmutex"></a>
+<h3>SolarMutex</h3>
+
+<p> A problem could arise if a thread that does not possess the SolarMutex
+ tries to execute a script synchronously, because any API call in the script
+can possibly acquire the SolarMutex. This may cause a deadlock, f.e. if the
+thread possessing the SolarMutex waits for a resource that is locked by the
+thread that tries to execute a script synchronously. So we could add some
+code here, that denies script execution, if it should be done synchronously
+and the SolarMutex is locked. It's better to treat this as an error than taking
+the risk of getting a deadlock. <br>
+ ======<br>
+ suffice to say that for synchronous executions the thread owns the SolarMutex,
+it doesn't need to be the "main" thread. <br>
+ ======<br>
+ Every not thread safe implementation of our API will acquire the SolarMutex
+in any interface call before anything will be done inside the method. So the
+function object doesn't need to care for that <br>
+ ======<br>
+ the SolarMutex should be locked only inside the API calls (it will be anyway),
+not by the function object (it mustn't, because it doesn't know if it is called
+synchronously or not!), the event handler or anybody else. A big advantage
+of this is, that the SolarMutex will be freed between two API calls, giving
+the message queue a chance to allow for a minimum responsiveness of the office
+process. The script then will work in parallel to the event queue. Only
+for synchronous execution we should try to (!) acquire the SolarMutex before
+executing the script as described above. If the try fails, script execution
+should be denied. I consider this to be a rare case, currently I can't imagine
+that any event that may cause a script execution will occur in a thread without
+the SolarMutex. But it's good to handle this case in an appropriate way.
+<br>
+ ======<br>
+ </p>
+
+<p> <a href="#contents">Contents</a> </p>
+
+<hr> <br>
+
+</body>
+</html>
diff --git a/content/udk/common/man/draft/scripting/basic-storage.html b/content/udk/common/man/draft/scripting/basic-storage.html
new file mode 100644
index 0000000..37b690d
--- /dev/null
+++ b/content/udk/common/man/draft/scripting/basic-storage.html
@@ -0,0 +1,310 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+<head>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
+ <TITLE></TITLE>
+ <META NAME="GENERATOR" CONTENT="OpenOffice.org 1.0 (Solaris Sparc)">
+ <META NAME="CREATED" CONTENT="20020626;15244200">
+ <META NAME="CHANGEDBY" CONTENT="Alexis Ledoux">
+ <META NAME="CHANGED" CONTENT="20020628;16180400">
+ <STYLE>
+ <!--
+ @page { margin-left: 3.18cm; margin-right: 3.18cm; margin-top: 2.54cm; margin-bottom: 2.54cm }
+ -->
+ </STYLE>
+</head>
+<body LANG="en-US">
+<BR><B>Process
+of creating a macro and assigning it to an event</B>
+<BR><BR>
+
+<BR>Assign a
+macro that was created and saved in the Standard Library of
+OpenOffice called Test().
+<BR>The
+directory <FONT SIZE=2><FONT FACE="Courier, monospace">soffice.cfg
+is created in the <FONT SIZE=2><FONT FACE="Courier, monospace">user/config
+directory once you assign a macro to a key.
+<BR>An xml
+file per context is created and contains all the bindings.
+<BR>Because
+the macro is in the Standard Library of OpenOffice and that the
+binding is only applied to a key in Writer:
+<BR> The file
+<FONT SIZE=2><FONT FACE="Courier, monospace">writerkeybinding.xml
+is created
+<BR><BR>
+
+<BR><B>Content
+of</B> <FONT SIZE=2><FONT FACE="Courier, monospace">writerkeybinding.xml
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><?xml
+version="1.0" encoding="UTF-8"?>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!DOCTYPE
+accel:acceleratorlist PUBLIC "-//OpenOffice.org//DTD
+OfficeDocument 1.0//EN" "accelerator.dtd">
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><accel:acceleratorlist
+xmlns:accel="http://openoffice.org/2001/accel"
+xmlns:xlink="http://www.w3.org/1999/xlink">
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ ...
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ <accel:item accel:code="KEY_F10"
+xlink:href="macro:///Standard.Module1.Alexis()"/>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ ...
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2></accel:acceleratorlist>
+<BR><BR>
+
+<BR><B>Content
+of</B> <FONT SIZE=2><FONT FACE="Courier, monospace">Accelerator.dtd
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ENTITY
+% boolean "(true|false)">
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ELEMENT
+accel:acceleratorlist (accel:item*)>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ATTLIST
+accel:acceleratorlist
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xmlns:accel
+CDATA #FIXED "http://openoffice.org/2001/accel"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xmlns:xlink
+CDATA #FIXED "http://www.w3.org/1999/xlink"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>>
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ELEMENT
+accel:item EMPTY>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ATTLIST
+accel:item
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> accel:code
+CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> accel:shift
+%boolean; "false"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> accel:mod1
+%boolean; "false"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> accel:mod2
+%boolean; "false"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xlink:href
+CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>>
+<BR><BR>
+
+<BR>The
+content of <FONT SIZE=2><FONT FACE="Courier, monospace">user/basic
+is formed by a directory per library you modified (in that case
+Standard was modified) and 2 files .xlc.
+<BR><FONT SIZE=2><FONT FACE="Courier, monospace">Script.xlc
+is the file that will be explained:
+<BR><BR>
+
+<BR><B>Content
+of the file</B> <FONT SIZE=2><FONT FACE="Courier, monospace">script.xlc
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><?xml
+version="1.0" encoding="UTF-8"?>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!DOCTYPE
+library:libraries PUBLIC "-//OpenOffice.org//DTD OfficeDocument
+1.0//EN" "libraries.dtd">
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+<library:libraries
+xmlns:library="http://openoffice.org/2000/library"
+xmlns:xlink="http://www.w3.org/1999/xlink">
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ <library:library library:name="Standard"
+xlink:href="file:///home/al91857/StarOffice6.0/user/basic/Standard/script.xlb/"
+xlink:type="simple" library:link="false"/>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ <library:library library:name="WebWizard"
+xlink:href="file:///usr/dist/share/staroffice,v6.0/share/basic/WebWizard/script.xlb/"
+xlink:type="simple" library:link="true"
+library:readonly="false"/>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+ ...
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+</library:libraries>
+<BR><BR>
+
+<BR><B>Content
+of </B><FONT SIZE=2><FONT FACE="Courier, monospace">Libraries.dtd
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ENTITY
+% boolean "(true|false)">
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ELEMENT
+library:libraries (library:library)*>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ATTLIST
+library:libraries
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xmlns:library
+CDATA #FIXED "http://openoffice.org/2000/library"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xmlns:xlink
+CDATA #FIXED "http://www.w3.org/1999/xlink"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>>
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ELEMENT
+library:library EMPTY>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ATTLIST
+library:library
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> library:name
+CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xlink:href
+CDATA #IMPLIED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xlink:type
+CDATA #IMPLIED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> library:link
+%boolean; #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> library:readonly
+%boolean; #IMPLIED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>>
+<BR><BR>
+
+<BR>You can
+see that the <FONT SIZE=2><FONT FACE="Courier, monospace">xlink:href
+of the <FONT SIZE=2><FONT FACE="Courier, monospace">library:name="Standard"
+is locating as file in the home directory because I modified that
+library.
+<BR><BR>
+
+<BR><B>Content
+of the file</B> <FONT SIZE=2><FONT FACE="Courier, monospace">script.xlb
+<B>in</B> <FONT SIZE=2><FONT FACE="Courier, monospace">file:///home/al91857/StarOffice6.0/user/basic/Standard
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><?xml
+version="1.0" encoding="UTF-8"?>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!DOCTYPE
+library:library PUBLIC "-//OpenOffice.org//DTD OfficeDocument
+1.0//EN" "library.dtd">
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><library:library
+xmlns:library="http://openoffice.org/2000/library"
+library:name="Standard" library:readonly="false"
+library:passwordprotected="false">
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+<library:element library:name="Module1"/>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2></library:library>
+<BR><BR>
+
+<BR><B>Content
+of</B> <FONT SIZE=2><FONT FACE="Courier, monospace">Library.dtd
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ENTITY
+% boolean "(true|false)">
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ELEMENT
+library:library (library:element)*>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ATTLIST
+library:library
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xmlns:library
+CDATA #FIXED "http://openoffice.org/2000/library"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+library:name CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+library:readonly %boolean; #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>
+library:passwordprotected %boolean; #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>>
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ELEMENT
+library:element EMPTY>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ATTLIST
+library:element
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> library:name
+CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>>
+<BR><BR>
+
+<BR><B>Content
+of the file where my macro was saved:</B> <FONT SIZE=2><FONT FACE="Courier, monospace">Module1.xba
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><?xml
+version="1.0" encoding="UTF-8"?>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!DOCTYPE
+script:module PUBLIC "-//OpenOffice.org//DTD OfficeDocument
+1.0//EN" "module.dtd">
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><script:module
+xmlns:script="http://openoffice.org/2000/script"
+script:name="Module1" script:language="StarBasic">REM
+ ***** BASIC *****
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>Sub
+Main
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>End
+Sub
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>Sub
+Alexis
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>print
+&quot;alexis&quot;
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>End
+Sub</script:module>
+<BR><BR>
+
+<BR><B>Content
+of</B> <FONT SIZE=2><FONT FACE="Courier, monospace">Module.dtd
+<BR><BR>
+
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ELEMENT
+script:module (#PCDATA)>
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2><!ATTLIST
+script:module
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> xmlns:script
+CDATA #FIXED "http://openoffice.org/2000/script"
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> script:name
+CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2> script:language
+CDATA #REQUIRED
+<BR><FONT FACE="Courier, monospace"><FONT SIZE=2>>
+<BR><BR>
+
+<BR>When
+you save the document including the macro, everything is in a Zip
+file with the same hierarchy than explained above.
+<BR><BR>
+
+<BR>The
+file hierarchy is:
+<BR><BR>
+
+<BR>Archive:
+ test.sxw
+<BR>
+ testing: content.xml
+<BR>
+ testing: Basic/Standard/Module1.xml
+<BR>
+ testing: Basic/Standard/script-lb.xml
+<BR>
+ testing: Basic/script-lc.xml
+<BR>
+ testing: styles.xml
+<BR>
+ testing: meta.xml
+<BR>
+ testing: settings.xml
+<BR>
+ testing: META-INF/manifest.xml
+<BR><BR>
+
+<BR>So
+the script-lb.xml file is the equivalent to the script.xlb file
+explained above
+<BR>The
+script-lc.xml file is the equivalent to the script.xlc file explained
+Above.
+</body>
+</HTML>
diff --git a/content/udk/common/man/draft/scripting/build-script.html b/content/udk/common/man/draft/scripting/build-script.html
new file mode 100644
index 0000000..7030577
--- /dev/null
+++ b/content/udk/common/man/draft/scripting/build-script.html
@@ -0,0 +1,296 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<html>
+<head>
+
+ <meta http-equiv="CONTENT-TYPE"
+ content="text/html; charset=iso-8859-1">
+ <title>Building Scripting</title>
+
+ <meta name="GENERATOR" content="OpenOffice.org 1.0 (Solaris Sparc)">
+
+ <meta name="CREATED" content="20020626;15244200">
+
+ <meta name="CHANGEDBY" content="Alexis Ledoux">
+
+ <meta name="CHANGED" content="20020628;16180400">
+
+ <style>
+ <!--
+ @page { margin-left: 3.18cm; margin-right: 3.18cm; margin-top: 2.54cm; margin-bottom: 2.54cm }
+ -->
+ </style>
+</head>
+ <body lang="en-US">
+
+<h2>Building the Scripting Framework for OpenOffice.org</h2>
+
+<h3>Contents:</h3>
+
+<ol>
+ <li><a href="#Requirements">Requirements</a></li>
+ <li><a href="#cvs">CVS</a></li>
+ <li><a href="#env">Setting up environment</a></li>
+ <li><a href="#modify">Modifying modules</a></li>
+ <li><a href="#build">Building</a></li>
+ <li><a href="#pkg">Create package</a></li>
+ <li><a href="#install">Manual install</a><br>
+ </li>
+
+</ol>
+ <br>
+ <br>
+
+<h3><a name="Requirements"></a>Requirements:</h3>
+
+<ul>
+ <li>JDK1.3 or greater</li>
+ <li>ANT which is available from <a
+ href="http://jakarta.apache.org/builds/jakarta-ant/release">http://jakarta.apache.org/builds/jakarta-ant/release</a></li>
+ <li>Full OO643C or later solver and installation set</li>
+ <li>OO643C or greater OpenOffice build environment (see: <a
+ href="http://www.openoffice.org/dev_docs/source/643/index.html/ondownloads">Downloading
+ and Building the Source</a>, currently this is for 643 not OO643C )</li>
+
+</ul>
+
+<h3><a name="cvs"></a>Projects to get from CVS</h3>
+Backup your unoil and offapi modules and then checkout the following:<br>
+ <br>
+ Modules to be checkout from CVS head:<br>
+
+<ul>
+ <li><i>scripting</i></li>
+ <li><i>unoil/drafts/com/sun/star/script (drafts/com/sun/star/script,
+ </i>needs to be in the <i>unoil </i> module)</li>
+ <li><i>offapi/drafts/com/sun/star/script </i><i>(drafts/com/sun/star/script,
+ </i>needs to be in the <i>offapi </i> module)</li>
+
+</ul>
+ If you only have solvers, you will also need to checkout the following
+ modules on a tag that is appropriate to the release, you are building
+for:<br>
+
+<ul>
+ <li><i>unoil</i></li>
+ <li><i>offapi</i></li>
+
+</ul>
+
+<h3><a name="env"></a>Setting up build environment for Scripting</h3>
+ <b>Assumption: </b>That you have a build environment set-up to build
+ OpenOffice.org or components for OpenOffice.org, otherwise please read
+the guide on <a
+ href="http://www.openoffice.org/dev_docs/source/643/index.html/ondownloads">Downloading
+ and Building the Source</a><br>
+ <br>
+ If you have configured your environment with Java and Ant, please skip
+ on to ...... , otherwise you will need to re-run the configure script from
+ the <i>config_office</i> project and include the options <i>--with-jdk-home=<PATH
+ TO JAVA> --with-ant-home=<PATH TO ANT></i> and source or
+ run the environment set-up script.<br>
+ <br>
+ <b>NOTE: </b>If configure can not get Ant, after you have sourced or
+ run the environment set-up script, you will need add all jarfiles
+ under <i><PATH TO ANT>/lib</i> to your <i>$CLASSPATH</i><br>
+ <br>
+
+<h3><a name="modify"></a>Modifying offapi, unoil and scripting modules for
+ building</h3>
+ You will need to modify the offapi and unoil modules so that the services
+ and interfaces for scripting are available.<br>
+
+<h4>offapi module:</h4>
+
+<ol>
+ <li>Ensure that you have the drafts/com/sun/star/script directory
+under the offapi module, if you don't, you will need to check it out from
+CVS head</li>
+ <li>Modify the prj/build.lst, you will need to add the following
+lines</li>
+
+ <ul>
+ <li><i>oa offapi\drafts\com\sun\star\script\framework
+ nmake - all oa_scriptf_drafts NULL</i></li>
+ <li><i>oa offapi\drafts\com\sun\star\script\framework\provider
+ nmake - all oa_sfprovider_drafts NULL</i></li>
+ <li><i>oa offapi\drafts\com\sun\star\script\framework\storage
+ nmake - all oa_sfstorage_drafts NULL</i></li>
+ <li>and add "<i>oa_sfprovider_drafts oa_sfstorage_drafts oa_scriptf_drafts</i>"
+ to the last line before "<i>NULL</i>"</li>
+
+ </ul>
+ <li> Modify the util/makefile.mk and add the following to UNOIDLDBFILES
+ list </li>
+
+ <ol>
+ <li>$(UCR)$/dcssscriptframework.db \ </li>
+ <li>$(UCR)$/dcsssfprovider.db \ </li>
+ <li>$(UCR)$/dcsssfstorage.db </li>
+
+ </ol>
+
+</ol>
+
+<h2></h2>
+
+<h4>unoil module:</h4>
+
+<ol>
+ <li>Ensure that you have the drafts/com/sun/star/script directory under
+ the unoil module, if you don't, you will need to check it out from CVS
+head</li>
+ <li>Modify the makefile.mk in the top level directory of the module
+-</li>
+
+ <ol>
+ <li>Change the line <i>RDB = $(SOLARBINDIR)/offapi.rdb</i>
+ to <i>RDB = $(PRJ)$/..$/offapi$/$(INPATH)$/ucr$/offapi.db</i></li>
+
+ </ol>
+ <li>Modify prj/build.lst</li>
+
+ <ol>
+ <li>Add the following line:<i> ul unoil\drafts\com\sun\star\script\framework
+ nmake - all ul_scriptf_drafts ul_ucb ul_frame NUL</i>L
+ <br>
+ </li>
+ <li>Add <i>ul_scriptf_drafts </i>to the last line before <i>NULL</i></li>
+
+ </ol>
+
+</ol>
+
+<h4>scripting module:</h4>
+
+<ol>
+ <li>Remove the comments from the lines in source/cppumaker.mk:</li>
+
+ <ol>
+ <li>UNOUCRDEP=$(PRJ)/../offapi/$(INPATH)/ucr/offapi.db $(SOLARBINDIR)$/udkapi.rdb
+ $(SOLARBINDIR)$/offapi.rdb</li>
+ <li>UNOUCRRDB=$(PRJ)/../offapi/$(INPATH)/ucr/offapi.db $(SOLARBINDIR)$/udkapi.rdb
+ $(SOLARBINDIR)$/offapi.rdb<br>
+ </li>
+
+ </ol>
+ <li>Comment out the lines in source/cppumaker.mk</li>
+
+ <ol>
+ <li>UNOUCRDEP=$(SOLARBINDIR)$/udkapi.rdb</li>
+ <li>UNOUCRRDB=$(SOLARBINDIR)$/udkapi.rdb</li>
+
+ </ol>
+ <li>Remove the comment from the following line in java/build.xml:</li>
+
+ <ol>
+ <li><!-- <pathelement location="${prj}/../unoil/${inpath}/class/unoil.jar"/>
+ --></li>
+
+ </ol>
+ <li>Comment out the line in java/build.xml:</li>
+ <ol>
+ <li><pathelement location="${solar.jar}/unoil.jar"/><br>
+ </li>
+ </ol>
+
+</ol>
+
+<h3><a name="build"></a>Building scripting</h3>
+
+<ol>
+ <li>Execute <i>build</i> in the <i>offapi</i> module</li>
+ <li>Execute <i>build </i>in the <i>unoil</i> module</li>
+ <li>Execute <i>build</i> in the <i>scripting</i> module</li>
+
+</ol>
+
+<h3><a name="pkg"></a>Creating the UNO Package:</h3>
+ Please read the <a
+ href="http://api.openoffice.org/DevelopersGuide/DevelopersGuide.html">Developer's
+ Guide</a> for more information on UNO packages<br>
+
+<ol>
+ <li>Create a separate directory (<i>$pkg)</i></li>
+ <li>In this directory, create directories called <i>$pkg/<PLATFORM>.plt
+ </i>and <i>$pkg/</i><i>skip_registration (</i>Where <i><PLATFORM></i>
+ is like linux_x86)</li>
+ <li><b>NOTE</b>: A list of supported directories is available in the
+source file desktop/source/pkgchk/pkgchk_packages.cxx, you may need to modify
+this, if your platform is not supported<br>
+ </li>
+ <li>Copy in the libraries from <i>scripting/<platform>/lib </i>to
+ <i>$pkg/</i><i><PLATFORM>.plt</i></li>
+ <li>Copy in <i>ScriptRuntimeForJava.jar</i> from <i>scripting/<platform>/class</i>
+ into the top level directory, <i>$pkg</i></li>
+ <li>Copy in <i>unoil.jar </i>from <i>$pkg/</i><i>unoil/<platform>/class
+ </i> to <i>skip_registration</i> directory<br>
+ </li>
+ <li>Merge the following registries from <i>offapi/<platform>/ucr
+ </i>into one registry called <i>ooscript.rdb</i> under the top level
+directory, <i>$pkg</i></li>
+
+ <ol>
+ <li><i>dcssscriptframework.db</i></li>
+ <li><i>dcsssfprovider.db</i></li>
+ <li><i>dcsssfstorage.db</i></li>
+
+ </ol>
+ <li>Now, zip up all files in this directory, <i>$pkg</i></li>
+
+</ol>
+
+<h3><a name="install"></a>Manual Installation of the Scripting Framework</h3>
+
+<ol>
+ <li>Copy the zip file into your OpenOffice installation under the user/uno_packages
+ directory <font color="#ff0000"></font></li>
+ <li>In the program directory, run pkgchk on the zip file</li>
+ <li>Copy from the solver<i> ($SRC_ROOT)/solver/643/<platform>/bin/</i><i>regsingleton</i>
+to your OpenOffice installation under the program directory<br>
+ </li>
+ <li>Execute the following: <font color="#ff0000"></font></li>
+
+ <ol>
+ <li><i>./regsingleton <OpenOffice Path>/user/uno_packages/cache/services.rdb
+ drafts.com.sun.star.script.framework.storage.theScriptStorageManager=drafts.com.sun.star.script.framework.storage.ScriptStorageManager</i></li>
+ <li><i>./regsingleton <OpenOffice Path>/user/uno_packages/cache/services.rdb
+ drafts.com.sun.star.script.framework.theScriptRuntimeForJava=drafts.com.sun.star.script.framework.ScriptRuntimeForJava</i></li>
+
+ </ol>
+ <li>Modify the the <i>ProtocolHandler.xcu</i> file under<i> <OpenOffice
+ Path>/share/registry/data/org/openoffice/Office/</i>, add the following
+ lines:</li>
+
+ <ol>
+ <li><node oor:name="com.sun.star.comp.ScriptProtocolHandler" oor:op="replace"><br>
+
+ <prop oor:name="Protocols"><br>
+
+ <value>script:*</value><br>
+
+ </prop><br>
+
+ </node><br>
+ Under the HandlerSet Tag</li>
+
+ </ol>
+
+</ol>
+ Unzip <i>HighlightTextParcel.sxp</i> from <i>scripting/examples/java </i>into
+ <i><OpenOffice Path>/user</i>, this should create a directory under
+ <i>user </i> called <i>Scripts/java/HighlightText</i><br>
+ <br>
+ Now, run OpenOffice and under the <i>Tools->Configure</i> menu add
+a new menu which is bound to the macro <i>Standard.Main</i>, then shut down
+ OpenOffice and modify the file <i><OpenOffice>/user/config/soffice.cfg/writermenubar.cfg</i>
+ and change <i>macro://Standard.main()</i> to <i>script://HighlightText.showForm.
+ </i>Start OpenOffice again and select the menu item you have added, this
+should bring up a Java dialog box call <i>HighlightText</i><br>
+ <br>
+ If you have any problems, please post your problem to <b><i>dev@framework.openoffice.org</i></b><br>
+ <br>
+ <br>
+ <br>
+ <br>
+</body>
+</html>
diff --git a/content/udk/common/man/draft/scripting/index.html b/content/udk/common/man/draft/scripting/index.html
new file mode 100644
index 0000000..d78dfcd
--- /dev/null
+++ b/content/udk/common/man/draft/scripting/index.html
@@ -0,0 +1,120 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html>
+<head><title>Language Independent Scripting Framework</title>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8"/>
+</head>
+<body>
+
+<h1>Language Independent Scripting Framework</h1>
+
+<h3>Nov 2002 - The Scripting Framework has now moved to the Application
+Framework project. The pages you find here are kept only for historical
+purposes. For up to date information on the project see
+<a href="http://framework.openoffice.org/scripting/index.html">
+the current Scripting Framework home page</a>.
+</h3>
+
+<p>This project is about enabling OpenOffice to be scripted in multiple
+scripting languages.. This page is to be used as a repository of information
+ relating to this project.<br/>
+ <br/>A team has been put together specifically for providing a language-agnostic
+ scripting framework for StarOffice. </p>
+<p>The team is in the process of defining the architecture and high level
+design for the scripting framework. The steps for this are:<br/>
+- provide a high level architecture (<a href="ArchDoc.20020618.sxw">Architecture Document</a>
+)<br/>
+- brainstorm possible user stories and compile them into a product requirements document (<a href="ProdReq.sxc">Product Requirements</a>
+)<br/>
+- analysis of major technical scripting framework issues (<a href="scripting-behaviour.sxw">Functional Areas, Interactions, Behaviour</a>
+)<br/>
+- provide high level design and interfaces for binding, invocation, naming, storage and IDE integration (in progress)<br/>
+- a number of research documents about the scripting framework issues, StarOffice areas involved and prototype are below</p>
+
+
+<p>Comments etc. (on the dev@udk.openoffice.org mailing list) will
+be really appreciated.</p>
+
+
+<p><b><font size="5">Documentation</font></b></p>
+<p><font size="5"><small>Architecture, high level design, product requirements<br/>
+</small><br/>
+</font></p>
+
+
+<table width="100%" cellspacing="1" cellpadding="4">
+ <tbody>
+ <tr>
+ <td bgcolor="#f0f0f0" valign="top"><a href="ArchDoc.20020618.sxw">Architecture Document</a></td>
+ <td bgcolor="#f0f0f0" valign="top">Language Agnostic Scripting
+ Framework high level architecture. </td>
+ </tr>
+ <tr>
+ <td bgcolor="#f0f0f0" valign="top"><a href="DesignDoc/">Design Document</a> <font color="#ff0000">New!</font></td>
+ <td bgcolor="#f0f0f0" valign="top">An initial design document containing class & interaction diagrams, proposals for the file structure, suggestions for the language-specific and logical names, DTD and XML for the script deployment and registry, and links to the proposed IDL files. </td>
+ </tr>
+ <tr>
+ <td bgcolor="#f0f0f0" valign="top"><a href="ProdReq.sxc">Product
+Requirements</a><br/>
+ </td>
+ <td bgcolor="#f0f0f0" valign="top">Product requirements (in
+ spreadsheet form). It contains the first cut of use cases grouped according
+ to associated user roles, specific product requirements and rough priorities
+ for implementation.<br/>
+ </td>
+ </tr><tr>
+ <td valign="top" bgcolor="#f0f0f0"><a href="scripting-behaviour.sxw">Functional areas, Interactions, Behaviour</a>
+ <br/>
+ </td>
+ <td valign="top" bgcolor="#f0f0f0">Analysis of major technical scripting framework issues.<br/>
+ </td>
+ </tr>
+
+
+
+
+
+</tbody>
+</table>
+ <br/>
+ <br/>
+<big>Research, prototype</big><br/>
+<br/>
+<table width="100%" bgcolor="#ffffff" cellspacing="1" cellpadding="4">
+<tbody><tr><td bgcolor="#f0f0f0" valign="top"><a href="JScriptWP.html">Java Scripting Framework</a></td><td bgcolor="#f0f0f0" valign="top">A document discussing
+some of the issues relating to a Java implementation of the Scripting
+Framework.</td></tr><tr><td bgcolor="#f0f0f0" valign="top"><a href="ProblemsIssues.html">Framework Problems & Issues</a> (Overview)<br/><ul><li><a href="code-management.html">Code management</a><br/></li><li><a href="thread-management.html">Thread management</a></li><li><a href="persistence.html">Persistence of script data</a></li><li><a href="symbol-resolution.html">Symbol/Dependency Resolution</a></li><li><a href="ide.txt">IDE requirements</a></li></ul></td><td bgcolor="#f0f0f0" v [...]
+of the main problem in the areas that need to be provided by the Scripting
+ Framework.<br/></td></tr><tr><td bgcolor="#f0f0f0" valign="top">Proposals for solutions<br/><ul><li><a href="BindingUI.html">Binding & binding UI</a></li><li><a href="ThreadingSoln.html">Threading</a></li><li><a href="StorageSolution.html">Script Storage<br/>
+ </a></li><li><a href="IDEIntegration.html">IDE Integration</a></li>
+</ul></td><td bgcolor="#f0f0f0" valign="top">Elaborations & proposals on
+some of the problem areas mentioned above.</td></tr></tbody>
+</table>
+<br/>
+
+<p><b><font size="5">Old Documentation</font></b> <br/>
+ </p>
+
+<table width="100%" bgcolor="#f0f0f0" cellspacing="1" cellpadding="4">
+ <tbody>
+ <tr>
+ <td bgcolor="#f0f0f0" valign="top"><a href="arch.txt">Architecture
+ Document</a></td>
+ <td bgcolor="#f0f0f0" valign="top">Language Agnostic Scripting
+ Framework architecture (deprecated).</td>
+ </tr>
+ <tr>
+ <td bgcolor="#f0f0f0" valign="top"><a href="archdiag.pdf">Architecture
+ Diagram</a></td>
+ <td bgcolor="#f0f0f0" valign="top">Scripting Framework architecture
+ diagram (PDF) (deprecated).</td>
+ </tr><tr>
+ <td valign="top" bgcolor="#f0f0f0"><a href="Services-and-interfaces.html">Services & Interfaces</a>
+ </td>
+ <td valign="top">A very basic first attempt
+ to define the necessary services & interfaces.</td>
+ </tr>
+
+
+ </tbody>
+</table>
+</body></html>
diff --git a/content/udk/common/man/idl.html b/content/udk/common/man/idl.html
new file mode 100644
index 0000000..d502e28
--- /dev/null
+++ b/content/udk/common/man/idl.html
@@ -0,0 +1,673 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+<head>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
+ <TITLE>Unoidl syntax description</TITLE>
+ <META NAME="GENERATOR" CONTENT="StarOffice/5.2 (Win32)">
+ <META NAME="CLASSIFICATION" CONTENT="Unoidl syntax description">
+ <META NAME="KEYWORDS" CONTENT="UNO,Unoidl,syntax,description">
+</head>
+<body LINK="#444488" VLINK="#444488" BGCOLOR="#eeeeff">
+<TABLE WIDTH=100% BORDER=0 CELLPADDING=4 CELLSPACING=0 STYLE="page-break-before: always">
+ <COL WIDTH=75>
+ <TR>
+ <TD BGCOLOR="#666699">
+ <H1 ALIGN=CENTER STYLE="margin-top: 0cm; text-decoration: none"><A HREF="http://www.openoffice.org/"><IMG SRC="../../images/open_office_org_logo.gif" NAME="Grafik1" ALT="OpenOffice" ALIGN=RIGHT WIDTH=109 HEIGHT=54 BORDER=0></A><FONT COLOR="#ffffff"><FONT SIZE=6>Unoidl
+ syntax description</FONT></FONT></H1>
+ </TD>
+ </TR>
+</TABLE>
+<HR SIZE=3 NOSHADE>
+<TABLE WIDTH=100% BORDER=0 CELLPADDING=4 CELLSPACING=0>
+ <COL WIDTH=61*>
+ <COL WIDTH=162*>
+ <COL WIDTH=32*>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3 ALIGN=LEFT STYLE="margin-top: 0cm; text-decoration: none"><FONT COLOR="#ffffff"><FONT SIZE=4>Contents</FONT></FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <A HREF="#Introduction">Introduction</A><BR>
+ <A HREF="#Keywords">Keywords</A><BR>
+ <A HREF="#Basetypes">Basetypes</A><BR>
+ <A HREF="#Comments">Comments</A><BR>
+ <A HREF="#Constants">Constants</A><BR>
+ <A HREF="#Enumeration">Enumeration</A><BR>
+ <A HREF="#Structure">Structure</A><BR>
+ <A HREF="#Typedef">Typedef</A><BR>
+ <A HREF="#Exception">Exception</A><BR>
+ <A HREF="#Interface">Interface</A><BR>
+ <A HREF="#Module">Module</A><BR>
+ <A HREF="#Service">Service</A><BR>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3 ALIGN=LEFT STYLE="margin-top: 0cm; text-decoration: none"><A NAME="Introduction"></A>
+ <FONT COLOR="#ffffff"><FONT SIZE=4>Introduction</FONT></FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P>The unoidl is an idl language (interface description language)
+ which is similar to the corba idl. Idl is a language to describe
+ interfaces and types independently of any programming language and
+ hardware platform. An idl description is used by the idl compiler
+ to generate code for these interfaces in a selected target
+ language. The generated code provide the use of the described
+ interfaces in the selected target language. The mapping of the idl
+ description to the target language was defined in an appropriate
+ language binding.
+ </P>
+ <P>All possible idl definitions will be described now. The reader
+ who is intimate in C++ programming will see, that the syntax of
+ the idl is similar to the C++ syntax. Because the lexical
+ conventions of the idl and the structure of the definitions have a
+ large degree with the ANSI standard for C++.</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Keywords"></A><FONT COLOR="#ffffff">Keywords</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P>The following table shows all keywords of the unoidl. All the
+ keywords are reserved and cannot be used as an identifier.</P>
+ <TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=0>
+ <COL WIDTH=43*>
+ <COL WIDTH=43*>
+ <COL WIDTH=43*>
+ <COL WIDTH=43*>
+ <COL WIDTH=43*>
+ <COL WIDTH=43*>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%>
+ <p>any</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>attribute</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>byte</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>boolean</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>char</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>const</p>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%>
+ <p>createAllListener</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>double</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>enum</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>exception</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>"FALSE"</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>"False"</p>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%>
+ <p>float</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>getreflection</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>hyper</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>ident</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>identifier</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>in</p>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%>
+ <p>includereflection</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>inout</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>interface</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>language</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>long</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>map</p>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%>
+ <p>mapping</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>module</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>name</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>needs</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>object</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>observes</p>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%>
+ <p>optional</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>out</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>property</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>raises</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>readonly</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>service</p>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%>
+ <p>sequence</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>short</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>string</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>struct</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>"TRUE"</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>"True"</p>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%>
+ <p>typedef</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>uik</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>unsigned</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>version</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>virtual</p>
+ </TD>
+ <TD WIDTH=17%>
+ <p>void</p>
+ </TD>
+ </TR>
+ </TABLE>
+ <BR>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Basetypes"></A><FONT COLOR="#ffffff">Basetypes</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P>The unoidl support the following basetypes:</P>
+ <DL>
+ <DD STYLE="margin-bottom: 0.51cm"><CODE>any,
+ boolean, byte, char, double, float, hyper, long, short, string,
+ void, unsigned hyper, unsigned long, unsigned short</CODE>
+ </DD>
+ </DL>
+ <P>The values TRUE and
+ FALSE (True and False) are defined for the <B><I>boolean</I></B>
+ type. The type <B><I>byte</I></B> is
+ a 1 byte type and represents a type which is not modified by the
+ transport to another computer. The representation of the type <B><I>char</I></B>
+ can be different on a computer which hardware/software
+ architecture is different. It depends on the representation of the
+ used charset. The type any is a type which can represent all
+ possible idl types.</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Comments"></A><FONT COLOR="#ffffff">Comments</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P>Comments are used to describe the source code. If the comment
+ support a special convention, it can be used for automatically
+ generation of documentation. The unoidl support 4 kinds of
+ comments:</P>
+ <UL>
+ <li><p><b>/* comment */</b></p>
+ <p>All characters between /* and */ are ignored by the idl
+ compiler. The characters /* are also ignored, so encapsulated
+ comments (comments in comments) are not allowed.</P>
+ <li><p><b>// comment end_of_line</b></p>
+ <p>With the characters // starts a comment which ends automatic
+ at the end of the line. All characters after // up to the end_
+ of_ line character are ignored.</P>
+ <li><p><b>/** comment */</b></p>
+ <p>The characters /** shows that a special comment for automatic
+ documentation generation begins. This kind of comment will be
+ saved as a special documentation string by the compiler for the
+ idl definition which follow this comment.</P>
+ <li><p><b>/// comment</b></p>
+ <p>The characters /// shows that a special comment for automatic
+ documentation generation begins. All characters after /// up to
+ the end_ of_ line character are saved as a special
+ documentation string for the next valid idl definition.</P>
+ </UL>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Constants"></A><FONT COLOR="#ffffff">Constants</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P><I>Definition:</I></P>
+ <DL>
+ <DD STYLE="margin-bottom: 0.51cm"><CODE>const
+ <TypeName> <ConstantName> "=" <Value>
+ ";"</CODE></DD></DL>
+ <P>
+ A constant definition begin with the keyword <B><I>const</I></B>
+ following by the identifier of a type (base_type), the identifier
+ of the constant and the assignment of a value. The value must be
+ in the range of the used type. The definition ends with a
+ semicolon. It is also possible to assign an expression. You can
+ combine values/expressions of the type [unsigned] hyper| long |
+ short with the operators *, /, %, +, -, <<, >>, &,
+ ^ and | which are known of C++.</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Enumeration"></A><FONT COLOR="#ffffff">Enumeration</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P><I>Definition:</I></P>
+ <DL>
+ <DD STYLE="margin-bottom: 0.51cm"><CODE>enum
+ <EnumName> "{" <EnumValue> [= Value] { ","
+ <EnumValue> [= Value] }* "}" ";"</CODE></DD></DL>
+ <P>
+ An enumeration definition begin with the keyword <B><I>enum</I></B>
+ following by the identifier of the enumeration type. The body of
+ the definition is bound with { } and the complete definition ends
+ with a semicolon. The body exists of an ordered list of
+ identifiers. It is possible to assign such an identifier a value
+ of the type long. The default numbering of the values is linear
+ and begin with 0 and crows with 1. If an identifier has an value,
+ all following identifiers without a value are numbered depending
+ on these last assignment of a value. All enum values of the body
+ are also known in the scope of enumeration type itself.</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Structure"></A><FONT COLOR="#ffffff">Structure</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P><I>Definition:</I></P>
+ <DL>
+ <DD STYLE="margin-bottom: 0.51cm"><CODE>struct
+ <StructureName> [ ":" <ExistStructureName>
+ ]<BR>"{"<BR>{ <ElementType> <ElementName>
+ ";" }+<BR>"}" ";"</CODE></DD></DL>
+ <P>
+ The definition of a structure begins with the keyword <B><I>struct</I></B>
+ following by the identifier of the structure. The body of the
+ definition is bound with { } and the complete definition ends with
+ a semicolon. Inside the body it is possible to define some
+ elements. An element definition begins with the identifier of the
+ type following by the identifier of the element name. The
+ definition end with a semicolon. The body of the structure is a
+ new namespace. Inside this namespace it is possible to use all
+ identifiers as names which are definite. It is possible to define
+ an inheritance for the structure. An inheritance will be defined
+ after the name identifier by a colon following an identifier of
+ the parent structure. Inheritance of structures is UNO specific
+ and not CORBA compatible.</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Typedef"></A><FONT COLOR="#ffffff">Typedef</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P><I>Definition:</I></P>
+ <DL>
+ <DD STYLE="margin-bottom: 0.51cm"><CODE>typedef
+ <TypeName> <NewTypeName> ";"</CODE></DD></DL>
+ <P>
+ A type definition begins with the keyword <B><I>typedef
+ </I></B>following by an identifier of an existing type and
+ the identifier of the new type. The definitions ends with a
+ semicolon</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Exception"></A><FONT COLOR="#ffffff">Exception</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P><I>Definition:</I></P>
+ <DL>
+ <DD STYLE="margin-bottom: 0.51cm"><CODE>exception
+ <ExceptionName> [ ":" <ExistExceptionName> ]<BR>
+ "{"<BR>
+ { <ElementType> <ElementName> ";" }*<BR>
+ "}" ";"</CODE></DD></DL>
+ <P>
+ The definition of an exception begins with the keyword <B><I>exception</I></B>
+ following by the identifier of the exception. The body of the
+ definition is bound with { } and the complete definition ends with
+ a semicolon. Inside the body it is possible to define some
+ members. A member definition begins with the identifier of the
+ type following by the identifier of the member name. The
+ definition end with a semicolon. The body of the structure is a
+ new namespace. Inside this namespace it is possible to use all
+ identifiers as names which are definite. It is possible to define
+ an inheritance for the exception. An inheritance will be defined
+ after the name identifier by a colon following an identifier of
+ the parent exception. Inheritance of exceptions is UNO specific
+ and not CORBA compatible.</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Interface"></A><FONT COLOR="#ffffff">Interface</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P><I>Definition:</I></P>
+ <DL>
+ <DD STYLE="margin-bottom: 0.51cm"><CODE>"["
+ uik"("<Uik>")""," ident"("
+ "\""<InterfaceName>"\"" ","
+ <VersionNummer>")" "]"<BR>
+ interface
+ <InterfaceName> [ ":" <InterfaceName> {,
+ <InterfaceName>}* ] <BR>
+ "{"<BR>
+ { <typedef>
+ | <struct> | <exception> | <constant> |
+ <enumeration> | <interface>}* { "["
+ [readonly ","] attribute "]" <TypeName>
+ <AttributeName> { "," <AttributeName>}* ";"
+ }*<BR>
+ { [ "["const | oneway "]" ] <TypeName>
+ <FunctionName> "(" [ <Parameter> { ","
+ <Parameter>}* ] ")" [ <Raises> ] ";"
+ }*<BR>
+ "}" ";"<BR>
+ <BR>
+ <Uik> =
+ xxxxxxxx-xxxx-xxxx-xxxxxxxx-xxxxxxxx ; x Î{0-9a-fA-F}<BR>
+ <Parameter>
+ = "[" in | out | inout "]" <TypeName>
+ <ParameterName><BR>
+ <Raises> = raises"("
+ <ExceptionName> { "," <ExceptionName>}* ")"</CODE>
+ </DD>
+ </DL>
+ <P>
+ An interface definition begins with an header which is bound with
+ [ ]. The header consists of an uik (universal interface key)
+ definition and an ident definition. The definition begins with the
+ keyword <B><I>uik</I></B> following
+ by a 32 byte number which is split in 5 blocks (8-4-4-8-8 byte)
+ and bound in ( ). The ident definition begins with the keyword
+ <B><I>ident</I></B> following by the
+ name of the interface and a version number. After the header
+ follows the keyword interfaces and an identifier for the interface
+ name. Optionally, an inheritance definition can follow. An
+ inheritance definition begins with a colon and one or more
+ identifiers of existing interfaces. The body of the interface is
+ bound with { } and the definition ends with a semicolon.<BR>An
+ interface opens a new namespace. There can be defined <A HREF="#Typedef">typedefs</A>,
+ <A HREF="#Structure">structs</A>, <A HREF="#Enumeration">enums</A>,
+ <A HREF="#Exception">exceptions</A>, <A HREF="#Constants">constants</A>
+ and <A HREF="#Interface">interfaces</A> and also specific
+ definitions for an interface:</P>
+ <UL>
+ <LI><P><CODE>"["
+ [readonly "," ] attribute "]" <TypeName>
+ <AttributeName> { "," <AttributeName>}*
+ ";"</CODE><BR>
+ An
+ attribute definition begins with a header which is bound with [
+ ]. In this header the keyword <B><I>attribute</I></B>
+ must be defined. Optional the keyword <B><I>readonly</I></B>
+ defined that the attribute can only accessed for reading. The
+ header follows an identifier for the attribute type and an
+ identifier for the attribute name or a list of identifiers. The
+ definition ends with a semicolon.</P>
+ </UL>
+ <UL>
+ <LI><P><CODE>"["const
+ | oneway "]" ] <TypeName> <FunctionName>
+ "(" [ <Parameter> { "," <Parameter>}*
+ ] ")" [ <Raises> ] ";"</CODE><BR>
+ A
+ function definition begins with an optional header following by
+ an identifier for the return type and an identifier for the
+ function name. The header is bound with [ ] and consists of the
+ flags <B><I>oneway</I></B> or <B><I>const</I></B>
+ or both. Oneway means that the function is asynchronous and don`t
+ wait for a reply. To use this flag the function must return void,
+ don`t take any out or inout parameters and don`t raise an
+ exception. Const means that the function don`t change the state
+ of the interface. The name of the function follows a parameter
+ definition which is bound in ( ) and a raises expression which is
+ optional.
+ </P>
+ <LI><P><CODE><Parameter>
+ = "[" in | out | inout "]" <TypeName>
+ <ParameterName></CODE><BR>
+ The
+ parameter definition begins with the direction flag which is
+ bound with [ ]. Valid flags for the direction are <B><I>in</I></B>
+ ( in parameter), <B><I>out</I></B>
+ (out parameter) or <B><I>inout</I></B>
+ (in and out parameter). The direction follows an identifier for
+ the parameter type and an identifier for the parameter name. More
+ than one parameter definitions are separated by comma.</P>
+ <LI><P><CODE><Raises>
+ = raises"(" <ExceptionName> { ","
+ <ExceptionName>}* ")"</CODE><BR>
+ The
+ raises definition begins with the keyword raises following by one
+ or more identifiers of existing exceptions which are bound with (
+ ). This named exceptions can be raised during the execution of
+ the function.</P>
+ </UL>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Module"></A><FONT COLOR="#ffffff">Module</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P><I>Definition:</I></P>
+ <DL>
+ <DD STYLE="margin-bottom: 0.51cm"><CODE>module
+ <ModuleName><BR>
+ "{"<BR>
+ { <typedef> |
+ <struct> | <exception> | <constant> |
+ <enumeration> | <interface> | <module> }*<BR>
+ "}" ";"
+ </CODE></DD>
+ </DL>
+ <P>
+ A module definition begins with the keyword <B><I>module</I></B>
+ following by the identifier of the module. The body of the
+ definition is bound with { } and the complete definition ends with
+ a semicolon. A module opens a new namespace and there can be
+ defined all valid idl definitions.</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Service"></A><FONT COLOR="#ffffff">Service</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P><I>Definition:</I></P>
+ <DL>
+ <DD STYLE="margin-bottom: 0.51cm"><CODE>service
+ <ServiceName><BR>
+ "{"<BR>
+ { "[" [readonly
+ "," ] property "]" <TypeName>
+ <PropertyName> { "," <PropertyName>}* ";"
+ }*<BR>
+ { interface <InterfaceName> { ","
+ <InterfaceName> }* ";" }*<BR>
+ { observes
+ <InterfaceName> { "," <InterfaceName> }*
+ ";" }*<BR>
+ { needs <ServiceName> { ","
+ <ServiceName> }* ";" }*<BR>
+ "}" ";"
+ </CODE></DD>
+ </DL>
+ <P>
+ A service definition begins with the keyword <B><I>service</I></B>
+ following by an identifier for the name of the service. Services
+ are principally for description and are UNO specific. The body of
+ the definition is bound with { } and the complete definition ends
+ with a semicolon.<BR>Definitions in a service:</P>
+ <UL>
+ <LI><P><CODE>"["
+ [readonly "," ] property "]" <TypeName>
+ <PropertyName> { "," <PropertyName>}* ";"
+ </CODE>
+ <A HREF="#object_property_def">(see object property
+ definition)</A></p>
+ <p> A <i>property</i> definition begins with a header which is
+ bound with [ ]. In this header the keyword
+ <B><I>property</I></B> must be defined. Optional the keyword
+ <B><I>readonly</I></B> defined that the property can only
+ accessed for reading. The header follows an identifier for the
+ property type and an identifier for the property name or a list
+ of identifiers. The definition ends with a semicolon.</P>
+ <LI><P><CODE>interface
+ <InterfaceName> { "," <InterfaceName> }*
+ ";"</CODE> <A HREF="#object_interface_def">(see
+ object interface definition)</A></p>
+ <p>An <i>interface</i> definition begins with the keyword
+ <B><I>interface</I></B> following by an identifier of an
+ existing interface or a list of identifiers of existing
+ interfaces. This definition in the scope of a service means
+ that the service provides the named interfaces. The definition
+ ends with a semicolon.</P>
+ </UL>
+ <UL>
+ <LI><P><CODE>observes
+ <InterfaceName> { "," <interfaceName> }*
+ ";"</CODE> <A HREF="#object_observes_def">(see
+ object observes definition)</A></p>
+ <p>An <i>observes</i> definition begins with the keyword
+ <B><I>observes</I></B> following by an identifier of an
+ existing interface or a list of identifiers of existing
+ interfaces. This definition in the scope of a service means
+ that the service must observe the named interfaces. The
+ definition ends with a semicolon.</P>
+ <LI><P><CODE>needs
+ <ServiceName> { "," <ServiceName> }* ";"</CODE>
+ <A HREF="#object_needs_def">(see
+ object needs definition)</A></p>
+ <p>A <i>needs</i> definition begins with the keyword
+ <B><I>needs</I></B> following by an identifier of an existing
+ service or a list of identifiers of existing services. This
+ definition in the scope of a service means that the service
+ needs the named services. The definition ends with a
+ semicolon.</P>
+ </UL>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <HR SIZE=1 NOSHADE>
+ </TD>
+ </TR>
+ <TR>
+ <TD WIDTH=50% BGCOLOR="#666699">
+ <P ALIGN=LEFT><FONT COLOR="#ffffff">
+ Author: <A HREF="mailto:juergen.schmidt@germany.sun.com"><FONT COLOR="#ffffff">Jürgen Schmidt</FONT></A> ($Date: 2004/10/29 02:01:05 $)<BR>
+ <I>Copyright 2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.</I></FONT>
+ </P>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <HR SIZE=1 NOSHADE>
+ </TD>
+ </TR>
+</TABLE>
+<HR SIZE=3 NOSHADE>
+</body>
+</HTML>
diff --git a/content/udk/common/man/idl_syntax.html b/content/udk/common/man/idl_syntax.html
new file mode 100644
index 0000000..9ce9e0b
--- /dev/null
+++ b/content/udk/common/man/idl_syntax.html
@@ -0,0 +1,534 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+<head>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
+ <TITLE>Unoidl syntax description</TITLE>
+ <META NAME="GENERATOR" CONTENT="StarOffice/5.2 (Win32)">
+ <META NAME="CLASSIFICATION" CONTENT="Unoidl syntax description">
+ <META NAME="KEYWORDS" CONTENT="UNO,Unoidl,syntax,description">
+</head>
+<body LINK="#444488" VLINK="#444488" BGCOLOR="#eeeeff">
+<TABLE WIDTH=100% BORDER=0 CELLPADDING=4 CELLSPACING=0 STYLE="page-break-before: always">
+ <COL WIDTH=75>
+ <TR>
+ <TD BGCOLOR="#666699">
+ <H1 ALIGN=CENTER STYLE="margin-top: 0cm; text-decoration: none"><A HREF="http://www.openoffice.org/"><IMG SRC="../../images/open_office_org_logo.gif" NAME="Grafik1" ALT="OpenOffice" ALIGN=RIGHT WIDTH=109 HEIGHT=54 BORDER=0></A><FONT COLOR="#ffffff"><FONT SIZE=6>Unoidl
+ syntax description</FONT></FONT></H1>
+ </TD>
+ </TR>
+</TABLE>
+<HR SIZE=3 noshade>
+<TABLE WIDTH=100% BORDER=0 CELLPADDING=4 CELLSPACING=0>
+ <COL WIDTH=61*> <COL WIDTH=162*> <COL WIDTH=32*>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3 ALIGN=LEFT STYLE="margin-top: 0cm; text-decoration: none"><FONT COLOR="#ffffff"><FONT SIZE=4>Contents</FONT></FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <p><A HREF="#Introduction">Introduction</A><BR>
+ <A HREF="#Keywords">Keywords</A><BR>
+ <A HREF="#Array">Basetypes<br>
+ </A> <A HREF="#Comments">Comments</A> <A HREF="#Array"><br>
+ Array </A><br>
+ <a href="#Union">Union</a> </p>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3 ALIGN=LEFT STYLE="margin-top: 0cm; text-decoration: none"><A NAME="Introduction"></A>
+ <FONT COLOR="#ffffff"><FONT SIZE=4>Introduction</FONT></FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P>The unoidl is an idl language (interface description language) which is
+ similar to the corba idl. Idl is a language to describe interfaces and
+ types independently of any programming language and hardware platform. An
+ idl description is used by the idl compiler to generate code for these
+ interfaces in a selected target language. The generated code provides the
+ use of the described interfaces in the selected target language. The
+ mapping of the idl description to the target language was defined in an
+ appropriate language binding. </P>
+ <P>All possible idl definitions will be described now. The reader who is
+ intimate in C++ programming will see, that the syntax of the idl is similar
+ to the C++ syntax. Because the lexical conventions of the idl and the
+ structure of the definitions have a large degree with the ANSI standard for
+ C++.</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Keywords"></A><FONT COLOR="#ffffff">Keywords</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P>The following table shows all keywords of the unoidl. All the keywords
+ are reserved and cannot be used as an identifier.</P>
+ <TABLE WIDTH=100% BORDER=1 CELLPADDING=4 CELLSPACING=0>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%><b>any</b></TD>
+ <TD WIDTH=17%><b>attribute</b></TD>
+ <TD WIDTH=17%><b>boolean</b></TD>
+ <TD WIDTH=17%><b>bound</b></TD>
+ <TD WIDTH=17%><b>byte</b></TD>
+ <TD WIDTH=17%><b>case</b></TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%><b>char</b></TD>
+ <TD WIDTH=17%><b>const</b></TD>
+ <TD WIDTH=17%><b>constants</b></TD>
+ <TD WIDTH=17%><b>constrained</b></TD>
+ <TD WIDTH=17%><b>default</b></TD>
+ <TD WIDTH=17%><b>double</b></TD>
+ </TR>
+ <COL WIDTH=43*> <COL WIDTH=43*> <COL WIDTH=43*> <COL WIDTH=43*> <COL WIDTH=43*>
+ <COL WIDTH=43*>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%>
+ <P><b>enum</b></P>
+ </TD>
+ <TD WIDTH=17%><b>exception</b></TD>
+ <TD WIDTH=17%><b>float</b></TD>
+ <TD WIDTH=17%>
+ <P><b>hyper</b></P>
+ </TD>
+ <TD WIDTH=17%>
+ <P><b>in</b></P>
+ </TD>
+ <TD WIDTH=17%>
+ <P><b>inout</b></P>
+ </TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%>
+ <P><b>interface</b></P>
+ </TD>
+ <TD WIDTH=17%>
+ <P><b>long</b></P>
+ </TD>
+ <TD WIDTH=17%>
+ <P ALIGN=LEFT><b>maybeambigious</b></P>
+ </TD>
+ <TD WIDTH=17%>
+ <P ALIGN=LEFT><b>maybedefault</b></P>
+ </TD>
+ <TD WIDTH=17%>
+ <P><b>maybevoid</b></P>
+ </TD>
+ <TD WIDTH=17%>
+ <P><b>module</b></P>
+ </TD>
+ </TR>
+ <tr valign=TOP>
+ <td width=17%>
+ <p><b>needs</b></p>
+ </td>
+ <td width=17%>
+ <p><b>observes</b></p>
+ </td>
+ <td width=17%>
+ <p><b>oneway</b></p>
+ </td>
+ <td width=17%>
+ <p><b>optional</b></p>
+ </td>
+ <td width=17%>
+ <p><b>out</b></p>
+ </td>
+ <td width=17%>
+ <p><b>property</b></p>
+ </td>
+ </tr>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%><b>raises</b></TD>
+ <TD WIDTH=17%><b>readonly</b></TD>
+ <TD WIDTH=17%><b>removable</b></TD>
+ <TD WIDTH=17%><b>sequence</b></TD>
+ <TD WIDTH=17%><b>service</b></TD>
+ <TD WIDTH=17%><b>short</b></TD>
+ </TR>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%><b>string</b></TD>
+ <TD WIDTH=17%><b>struct</b></TD>
+ <TD WIDTH=17%><b>switch</b></TD>
+ <TD WIDTH=17%><b>transient</b></TD>
+ <TD WIDTH=17%><b>type</b></TD>
+ <TD WIDTH=17%><b>typedef</b></TD>
+ </TR>
+ <tr valign=TOP>
+ <td width=17%><b>union</b></td>
+ <td width=17%><b>unsigned</b></td>
+ <td width=17%><b>void</b></td>
+ <td width=17%><b>FALSE</b></td>
+ <td width=17%><b>False</b></td>
+ <td width=17%><b>TRUE</b></td>
+ </tr>
+ <TR VALIGN=TOP>
+ <TD WIDTH=17%><b>True</b></TD>
+ <TD WIDTH=17%> </TD>
+ <TD WIDTH=17%> </TD>
+ <TD WIDTH=17%> </TD>
+ <TD WIDTH=17%> </TD>
+ <TD WIDTH=17%> </TD>
+ </TR>
+ </TABLE>
+ <BR>
+ </TD>
+ </TR>
+ <tr>
+ <td colspan=3 width=100% bgcolor="#666699">
+ <h3><a name="IDL_Specification"></a><font color="#FFFFFF">IDL language specification</font></h3>
+ </td>
+ </tr>
+ <tr>
+ <td colspan=3 width=100%>
+ <p><i>Definition:</i></p>
+ <pre>
+<b><a name="1"></a><font color="#FF0000">(1)</font> <idl_specification> := <definition>+
+
+<a name="2"></a><font color="#FF0000">(2)</font> <definition> := <type_decl> ";"
+ | <module_decl> ";"
+ | <constant_decl> ";"
+ | <exception_decl> ";"
+ | <constants_decl> ";"
+ | <service_decl> ";"
+
+<font color="#FF0000"><a name="3"></a>(3)</font> <type_decl> := <interface>
+ | <struct_decl>
+ | <enum_decl>
+ | <union_decl>
+ | "typedef" <type_spec> <declarator> {"," <declarator> }*
+
+<a name="4"></a><font color="#FF0000">(4)</font> <interface> := <interface_decl>
+ | <forward_decl>
+
+<font color="#FF0000"><a name="5"></a>(5)</font> <forward_decl> := "interface" <identifier>
+
+<font color="#FF0000"><a name="6"></a>(6)</font> <interface_decl> := <interface_header> "{" <interface_body> "}"
+
+<font color="#FF0000"><a name="7"></a>(7)</font> <interface_header> := "interface" <identifier> [ <interface_inheritance> ]
+
+<font color="#FF0000"><a name="8"></a>(8)</font> <interface_inheritance> := ":" <interface_name>
+
+<font color="#FF0000"><a name="9"></a>(9)</font> <interface_name> := <scoped_name>
+
+<font color="#FF0000"><a name="10"></a>(10)</font> <scoped_name> := <identifier>
+ | "::" <scoped_name>
+ | <scoped_name> "::" <identifier>
+
+<font color="#FF0000"><a name="11"></a>(11)</font> <interface_body> := <export>+
+
+<font color="#FF0000"><a name="12"></a>(12)</font> <export> := <attribute_decl> ";"
+ | <operation_decl> ";"
+
+<font color="#FF0000"><a name="13"></a>(13)</font> <attribute_decl> := <attribute_head> <type_spec> <declarator> { "," <declarator> }*
+
+<font color="#FF0000"><a name="14"></a>(14)</font> <attribute_head> := "[" ["readonly" ","] "attribute" "]"
+ | "[" "attribute" ["," "readonly"] "]"
+
+
+<font color="#FF0000"><a name="15"></a>(15)</font> <declarator> := <identifier>
+ | <array_declarator>
+
+<font color="#FF0000"><a name="16"></a>(16)</font> <array_declarator> := <identifier> <array_size>+
+
+<font color="#FF0000"><a name="17"></a>(17)</font> <array_size> := "[" <positive_int> "]"
+
+<font color="#FF0000"><a name="18"></a>(18)</font> <positive_int> := <const_expr>
+
+<font color="#FF0000"><a name="19"></a>(19)</font> <type_spec> := <simple_type_spec>
+ | constr_type_spec>
+
+<font color="#FF0000"><a name="20"></a>(20)</font> <simple_type_spec> := <base_type_spec>
+ | <template_type_spec>
+ | <scoped_name>
+
+<font color="#FF0000"><a name="21"></a>(21)</font> <base_type_spec> := <integer_type>
+ | <floating_point_type>
+ | <char_type>
+ | <byte_type>
+ | <boolean_type>
+ | <string_type>
+ | <any_type>
+ | <type_type>
+
+<font color="#FF0000"><a name="22"></a>(22)</font> <template_type> := <sequence_type>
+ | <array_type>
+
+<font color="#FF0000"><a name="23"></a>(23)</font> <sequence_type> := "sequence" "<" <type_spec> ">"
+
+<font color="#FF0000"><a name="24"></a>(24)</font> <array_type> := <type_spec> <array_size>+
+
+<font color="#FF0000"><a name="25"></a>(25)</font> <floating_point_type> := "float"
+ | "double"
+
+<font color="#FF0000"><a name="26"></a>(26)</font> <integer_type> := <signed_int>
+ | <unsinged_int>
+
+<font color="#FF0000"><a name="27"></a>(27)</font> <signed_int> := "short"
+ | "long"
+ | "hyper"
+
+
+<font color="#FF0000"><a name="28"></a>(28)</font> <unsigned_int> := "unsigned" "short"
+ | "unsigned" "long"
+ | "unsigned" "hyper"
+
+<font color="#FF0000"><a name="29"></a>(29)</font> <char_type> := "char"
+
+<font color="#FF0000"><a name="30"></a>(30)</font> <type_type> := "type"
+
+<font color="#FF0000"><a name="31"></a>(31)</font> <string_type> := "string"
+
+<font color="#FF0000"><a name="32"></a>(32)</font> <byte_type> := "byte"
+
+<font color="#FF0000"><a name="33"></a>(33)</font> <any_type" := "any"
+
+<font color="#FF0000"><a name="34"></a>(34)</font> <boolean_type> := "boolean"
+
+<font color="#FF0000"><a name="35"></a>(35)</font> <constr_type_spec> := <struct_type>
+ | <enum_type>
+ | <union_type>
+
+<font color="#FF0000"><a name="36"></a>(36)</font> <struct_type> := "struct" <identifier> [ <struct_inheritance> ] "{" <member>+ "}"
+
+<font color="#FF0000"><a name="37"></a>(37)</font> <struct_inheritance> := ":" <scoped_name>
+
+<font color="#FF0000"><a name="38"></a>(38)</font> <member> := <type_spec> <declarator> { "," <declarator> }*
+
+<font color="#FF0000"><a name="39"></a>(39)</font> enum_type> := enum <identifier> "{" <enumerator> { "," <enumerator> }* "}"
+
+<font color="#FF0000"><a name="40"></a>(40)</font> <enumerator> := <identifier> [ "=" <positive_int> ]
+
+<font color="#FF0000"><a name="41"></a>(41)</font> <union_type> := "union" <identifier> "switch" "(" <switch_type_spec> ")"
+ "{" <switch_body> "}"
+
+<font color="#FF0000"><a name="42"></a>(42)</font> <switch_type_spec> := <integer_type>
+ | <enum_type>
+ | <scoped_name>
+
+<font color="#FF0000"><a name="43"></a>(43)</font> <switch_body> := <case>+
+
+<font color="#FF0000"><a name="44"></a>(44)</font> <case> := <case_label> <element_spec> ";"
+
+<font color="#FF0000"><a name="45"></a>(45)</font> <case_label> := "case" <const_expr> ":"
+ | "default" ":";
+
+<font color="#FF0000"><a name="46"></a>(46)</font> <element_spec> := <type_spec> <declarator>
+
+<font color="#FF0000"><a name="47"></a>(47)</font> <exception_decl> := "exception" <identifier> [ <exception_inheritance> ] "{" <member>* "}"
+
+<font color="#FF0000"><a name="48"></a>(48)</font> <exception_inheritance> := ":" <scoped_name>
+
+<font color="#FF0000"><a name="49"></a>(49)</font> <module_decl> := "module" <identifier> "{" <definition>+ "}"
+
+<font color="#FF0000"><a name="50"></a>(50)</font> <constant_decl> := "const" <const_type> <identifier> "=" <const_expr>
+
+<font color="#FF0000"><a name="51"></a>(51)</font> <const_type> := <integer_type>
+ | <char_type>
+ | <boolean_type>
+ | <floating_point_type>
+ | <string_type>
+ | <scoped_name>
+
+<font color="#FF0000"><a name="52"></a>(52)</font> <const_expr> := <or_expr>
+
+<font color="#FF0000"><a name="53"></a>(53)</font> <or_expr> := <xor_expr>
+ | <or_expr> "|" <xor_expr>
+
+<font color="#FF0000"><a name="54"></a>(54)</font> <xor_expr> := <and_expr><br> | <xor_expr> "^" <and_expr>
+
+<font color="#FF0000"><a name="55"></a>(55)</font> <and_expr> := <shift_expr>
+ | <and_expr> "&" <shift_expr>
+
+<font color="#FF0000"><a name="56"></a>(56)</font> <shift_expr> := <add_Expr>
+ | <shift_expr ">>" <add_expr>
+ | <shift_expr "<<" <add_expr>
+
+<font color="#FF0000"><a name="57"></a>(57)</font> <add_expr> := <mult_expr>
+ | <add_expr> "+" <mult_expr>
+ | <add_expr> "-" <mult_expr>
+
+<font color="#FF0000"><a name="58"></a>(58)</font> <mult_Expr> := <unary_expr>
+ | <mult_expr> "*" <unary_expr>
+ | <mult_expr> "/" <unary_expr>
+ | <mult_expr> "%" <unary_expr>
+
+<font color="#FF0000"><a name="59"></a>(59)</font> <unary_expr> := <unary_operator><primary_expr>
+ | <primary_expr>
+
+<font color="#FF0000"><a name="60"></a>(60)</font> <unary_operator> := "-" | "+" | "~"
+
+<font color="#FF0000"><a name="61"></a>(61)</font> <primary_expr> := <scoped_name>
+ | <literal>
+ | "(" <const_expr> ")"
+
+<font color="#FF0000"><a name="62"></a>(62)</font> <literal> := <integer_literal>
+ | <string_literal>
+ | <character_literal>
+ | <floating_point_literal>
+ | <boolean_literal>
+
+<font color="#FF0000"><a name="63"></a>(63)</font> <boolean_literal> := "TRUE"
+ | "True"
+ | "FALSE"
+ | "False"
+<font color="#FF0000"><a name="64"></a>(64)</font> <service_decl> := "service" <identifier> "{" <service_member>+ "}"
+
+<font color="#FF0000"><a name="65"></a>(65)</font> <service_member> := <property_decl> ";"
+ | <support_decl> ";"
+ | <export_decl> ";"
+ | <observe_decl> ";"
+ | <needs_decl> ";"
+
+<font color="#FF0000"><a name="66"></a>(66)</font> <property_decl> := <property_head> <type_spec> <declarator> { "," <declarator> }*
+
+<font color="#FF0000"><a name="67"></a>(67)</font> <property_head> := "[" {<property_flags> ","}* "property" "]"
+ | "[" "property" {"," <property_flags>}* "]"
+
+<font color="#FF0000"><a name="68"></a>(68)</font> <property_flags> := "readonly"
+ | "bound
+ | "constrained"
+ | "maybeambigious"
+ | "maybedefault"
+ | "maybevoid"
+ | "optional"
+ | "removable"
+ | "transient"
+
+<font color="#FF0000"><a name="69"></a>(69)</font> <support_decl> := "interface" <declarator> { "," <declarator> }*
+
+<font color="#FF0000"><a name="70"></a>(70)</font> <export_decl> := "service" <declarator> { "," <declarator> }*
+
+<font color="#FF0000"><a name="71"></a>(71)</font> <observe_decl> := "observe" <declarator> { "," <declarator> }*
+
+<font color="#FF0000"><a name="72"></a>(72)</font> <needs_decl> := "needs" <declarator> { "," <declarator> }*
+
+<font color="#FF0000"><a name="73"></a>(73)</font> <constants_decl> := "constants" <identifier> "{" <constant_decl>+ "}"
+| </b></pre>
+ </td>
+ </tr>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Basetypes"></A><FONT COLOR="#ffffff">Basetypes</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P>The unoidl supports the following basetypes:</P>
+ <table width="100%" border="1">
+ <tr>
+ <td><b>any</b></td>
+ <td><b>boolean</b></td>
+ <td><b>byte</b></td>
+ <td><b>char</b></td>
+ <td><b>double</b></td>
+ <td><b>float</b></td>
+ <td><b>hyper</b></td>
+ <td><b>long</b></td>
+ </tr>
+ <tr>
+ <td><b>short</b></td>
+ <td><b>string</b></td>
+ <td><b>type</b></td>
+ <td><b>void</b></td>
+ <td><b>unsigned hyper</b></td>
+ <td><b>unsigned long</b></td>
+ <td><b>unsigned short</b></td>
+ <td> </td>
+ </tr>
+ </table>
+ <P>The values <b>TRUE</b> and <b>FALSE</b> (<b>True</b> and <b>False</b>)
+ are defined for the <B><I>boolean</I></B> type. The type
+ <B><I>byte</I></B> is a 1 byte type and represents a type which is not
+ modified by the transport to another computer. The representation of the
+ type <B><I>char</I></B> can be different on a computer which
+ hardware/software architecture is different. It depends on the
+ representation of the used charset. The type <b>any</b> is a type which
+ can represent all possible idl types. The type <b>type</b> is a metatype
+ which describes other types defined in IDL.</P>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Comments"></A><FONT COLOR="#ffffff">Comments</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P>Comments are used to describe the source code. If the comment support
+ a special convention, it can be used for automatically generation of
+ documentation. The unoidl support 4 kinds of comments:</P>
+ <UL>
+ <LI>
+ <p><b>/* comment */</b></p>
+ <p>All characters between /* and */ are ignored by the idl compiler.
+ The characters /* are also ignored, so encapsulated comments are not
+ allowed.</P>
+ <LI>
+ <p><b>// comment end_of_line</b></p>
+ <p>With the characters // starts a comment which ends automatic at
+ the end of the line. All characters after // up to the end_ of_ line
+ character are ignored.</p>
+ <LI>
+ <p><b>/** comment */</b></p>
+ <p>The characters /** shows that a special comment for automatic
+ documentation generation begins. This kind of comment will be saved
+ as a special documentation string by the compiler for the idl
+ definition which follow this comment.</p>
+ <LI>
+ <p><b>/// comment</b></p>
+ <p>The characters /// shows that a special comment for automatic
+ documentation generation begins. All characters after /// up to the
+ end_ of_ line character are saved as a special documentation string
+ for the next valid idl definition.</p>
+ </UL>
+ </TD>
+ </TR>
+ <tr>
+ <td colspan=3 width=100% bgcolor="#666699">
+ <h3><a name="Array"></a><font color="#FFFFFF">Array (not final, arrays can
+ not be used in UNO at this time)</font></h3>
+ </td>
+ </tr>
+ <tr>
+ <td colspan=3 width=100%>
+ <p>Arrays are not final specified in the UNO IDL and can not be used with
+ UNO at this time!!!</p>
+ </td>
+ </tr>
+ <tr>
+ <td colspan=3 width=100% bgcolor="#666699">
+ <h3><a name="Union"></a><font color="#FFFFFF">Union (not final, unions can
+ not be used in UNO at this time)</font></h3>
+ </td>
+ </tr>
+ <tr>
+ <td colspan=3 width=100%>
+ <p>Unions are not final specified in the UNO IDL and can not be used with
+ UNO at this time!!!</p>
+ </td>
+ </tr>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <HR SIZE=1 noshade>
+ </TD>
+ </TR>
+ <TR>
+ <TD WIDTH=50% BGCOLOR="#666699">
+ <P ALIGN=LEFT><FONT COLOR="#ffffff"> Author: <A HREF="mailto:juergen.schmidt@germany.sun.com"><FONT COLOR="#ffffff">Jürgen
+ Schmidt</FONT></A> ($Date: 2004/10/29 06:35:09 $)<BR>
+ <I>Copyright 2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA.</I></FONT>
+ </P>
+ </TD>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <HR SIZE=1 noshade>
+ </TD>
+ </TR>
+</TABLE>
+</body>
+</HTML>
diff --git a/content/udk/common/man/lifecycle.html b/content/udk/common/man/lifecycle.html
new file mode 100644
index 0000000..0d6a049
--- /dev/null
+++ b/content/udk/common/man/lifecycle.html
@@ -0,0 +1,308 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http:://www.w3.org/TR/html4/strict.dtd">
+<HTML>
+<head>
+ <TITLE>UNO Object Life Cycle Model</TITLE>
+
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+
+<TABLE WIDTH="100%" BORDER="0" CELLSPACING="0" CELLPADDING="4">
+ <TR><TD BGCOLOR="#666699">
+ <H1 ALIGN="CENTER" STYLE="margin-top: 0in; text-decoration: none"><!--
+ --><A HREF="http://www.openoffice.org"><IMG
+ SRC="../../images/open_office_org_logo.gif" ALT="OpenOffice.org"
+ ALIGN="RIGHT" BORDER="0"></A><FONT COLOR="White">UNO Object Life
+ Cycle Model</FONT></H1>
+ </TD></TR>
+</TABLE>
+<HR NOSHADE SIZE="3"/>
+
+<H1>Specification</H1>
+
+<P>This model is built on four abstractions: threads, objects, data items, and
+time.</P>
+
+<P>There is a set of <DFN>threads</DFN>, which are not further specified here
+(see <A href="execution.html"><CITE>UNO Execution Model</CITE></A> for
+details). At any time, this thread pool owns a specific set of data items.</P>
+
+<P>For simplicity (but without loss of generality), a fixed, infinite set of
+<DFN>objects</DFN>, <VAR>O</VAR>, is assumed. At any time, each object
+owns a specific set of data items.</P>
+
+<P><DFN>Data items</DFN> consist of values of the primitive and structured UNO
+types (see <A HREF="typesystem.html"><CITE>UNO Type System</CITE></A>), and of
+object references (representing the interface types). An object reference is
+either the null reference or a reference to any object <VAR>o</VAR> ∈
+<VAR>O</VAR>.</P>
+
+<P>At any time <VAR>t</VAR>, <VAR>TRef</VAR><SUB><VAR>t</VAR></SUB> ⊆
+<VAR>O</VAR> is the set of <DFN>objects directly referenced from the thread
+pool</DFN>. These are all the objects referenced from the data items owned by
+the thread pool at time <VAR>t</VAR>.</P>
+
+<P>At any time <VAR>t</VAR>, for each object <VAR>o</VAR> ∈
+<VAR>O</VAR>, <VAR>ref</VAR><SUB><VAR>t</VAR></SUB>(<VAR>o</VAR>) ⊆
+<VAR>O</VAR> is the set of <DFN>objects directly referenced from
+object <VAR>o</VAR></DFN>. These are all the objects referenced from the
+data items owned by object <VAR>o</VAR> at time <VAR>t</VAR>.
+The function <VAR>ref</VAR><SUP>+</SUP><SUB><VAR>t</VAR></SUB> is the transitive
+hull of the function <VAR>ref</VAR><SUB><VAR>t</VAR></SUB>; at any
+time <VAR>t</VAR>,
+<VAR>ref</VAR><SUP>+</SUP><SUB><VAR>t</VAR></SUB>(<VAR>o</VAR>) represents the
+set of <DFN>objects referenced from object <VAR>o</VAR></DFN>. Viewed as
+a relation, <VAR>ref</VAR><SUB><VAR>t</VAR></SUB> describes a directed graph
+with objects as vertices and object references as edges. An <DFN>object
+reference circle</DFN> is a strongly connected component of that graph, with the
+restriction that it must contain at least one edge. (Informally, an object
+reference circle is a maximal set of objects where each object can be reached
+from every other object via one or more object references.)</P>
+
+<P>At any time <VAR>t</VAR>,
+<VAR>TRef</VAR><SUP>+</SUP><SUB><VAR>t</VAR></SUB> :=
+<VAR>TRef</VAR><SUB><VAR>t</VAR></SUB> ∪
+<FONT SIZE="+1">∪</FONT><SUB><VAR>o</VAR> ∈
+<VAR>TRef</VAR><SUB><VAR>t</VAR></SUB></SUB>
+<VAR>ref</VAR><SUP>+</SUP><SUB><VAR>t</VAR></SUB>(o) is the set of <DFN>objects
+referenced from the thread pool</DFN>.</P>
+
+<P>At any time <VAR>t</VAR>, <VAR>O</VAR> can be partitioned into four
+disjoint subsets: the <DFN>immaterial objects</DFN>
+<VAR>Imm</VAR><SUB><VAR>t</VAR></SUB>, the <DFN>active objects</DFN>
+<VAR>Act</VAR><SUB><VAR>t</VAR></SUB>, the <DFN>done objects</DFN>
+<VAR>Don</VAR><SUB><VAR>t</VAR></SUB>, and the <DFN>unreachable objects</DFN>
+<VAR>Unr</VAR><SUB><VAR>t</VAR></SUB>. Two of these are derived as follows:
+<VAR>Act</VAR><SUB><VAR>t</VAR></SUB> :=
+<VAR>TRef</VAR><SUP>+</SUP><SUB><VAR>t</VAR></SUB>, and
+<VAR>Unr</VAR><SUB><VAR>t</VAR></SUB> := <VAR>O</VAR> \
+(<VAR>Imm</VAR><SUB><VAR>t</VAR></SUB> ∪
+<VAR>Act</VAR><SUB><VAR>t</VAR></SUB> ∪
+<VAR>Don</VAR><SUB><VAR>t</VAR></SUB>).</P>
+
+<P>Initial state:</P>
+<UL>
+ <LI><VAR>TRef</VAR><SUB>0</SUB> := ∅</LI>
+
+ <LI>for all <VAR>o</VAR> ∈ <VAR>O</VAR>,
+ <VAR>ref</VAR><SUB>0</SUB>(<VAR>o</VAR>) := ∅</LI>
+
+ <LI><VAR>Imm</VAR><SUB>0</SUB> := <VAR>O</VAR></LI>
+
+ <LI><VAR>Don</VAR><SUB>0</SUB> := ∅</LI>
+</UL>
+
+<P>Transitions:</P>
+<DL>
+ <DT><STRONG>adjust threads</STRONG></DT>
+ <DD><VAR>s</VAR> ⊆
+ <VAR>TRef</VAR><SUP>+</SUP><SUB><VAR>t</VAR></SUB> →<BR/>
+  <VAR>TRef</VAR><SUB><VAR>t</VAR> + 1</SUB> := <VAR>s</VAR><BR/>
+  <VAR>Don</VAR><SUB><VAR>t</VAR> + 1</SUB> :=
+ <VAR>Don</VAR><SUB><VAR>t</VAR></SUB> ∪ {<VAR>o</VAR> ∈
+ <VAR>TRef</VAR><SUP>+</SUP><SUB><VAR>t</VAR></SUB> \
+ <VAR>TRef</VAR><SUP>+</SUP><SUB><VAR>t</VAR> + 1</SUB> | <VAR>o</VAR>
+ ∉
+ <VAR>ref</VAR><SUP>+</SUP><SUB><VAR>t</VAR> + 1</SUB>(<VAR>o</VAR>)}</DD>
+
+ <DT><STRONG>adjust object</STRONG></DT>
+ <DD><VAR>o</VAR> ∈ <VAR>TRef</VAR><SUP>+</SUP><SUB><VAR>t</VAR></SUB>,
+ <VAR>s</VAR> ⊆
+ <VAR>TRef</VAR><SUP>+</SUP><SUB><VAR>t</VAR></SUB> →<BR/>
+  <VAR>ref</VAR><SUB><VAR>t</VAR> + 1</SUB>(<VAR>o</VAR>) :=
+ <VAR>s</VAR><BR/>
+  <VAR>Don</VAR><SUB><VAR>t</VAR> + 1</SUB> :=
+ <VAR>Don</VAR><SUB><VAR>t</VAR></SUB> ∪ {<VAR>o</VAR> ∈
+ <VAR>TRef</VAR><SUP>+</SUP><SUB><VAR>t</VAR></SUB> \
+ <VAR>TRef</VAR><SUP>+</SUP><SUB><VAR>t</VAR> + 1</SUB> | <VAR>o</VAR>
+ ∉
+ <VAR>ref</VAR><SUP>+</SUP><SUB><VAR>t</VAR> + 1</SUB>(<VAR>o</VAR>)}</DD>
+
+ <DT><STRONG>create object</STRONG></DT>
+ <DD><VAR>o</VAR> ∈
+ <VAR>Imm</VAR><SUB><VAR>t</VAR></SUB> →<BR/>
+  <VAR>TRef</VAR><SUB><VAR>t</VAR> + 1</SUB> :=
+ <VAR>TRef</VAR><SUB><VAR>t</VAR></SUB> ∪ {<VAR>o</VAR>}<BR/>
+  <VAR>Imm</VAR><SUB><VAR>t</VAR> + 1</SUB> :=
+ <VAR>Imm</VAR><SUB><VAR>t</VAR></SUB> \ {<VAR>o</VAR>}</DD>
+</DL>
+
+<H1>Explanation</H1>
+
+<P>Over time, each individual object can transition from <VAR>Imm</VAR> to
+<VAR>Act</VAR>, and then to either <VAR>Don</VAR> or <VAR>Unr</VAR>. Each
+object starts out as immaterial. The set of data items owned by an immaterial
+object (and hence its set of directly referenced objects) is empty. An object
+becomes active once it has been created, and stays active as long as it is
+referenced from the thread pool. The set of data items owned by an object (and
+hence its set of directly referenced objects) can only change while the object
+is active. An object becomes done once neither it is referenced from the thread
+pool, nor is it a member of an object reference circle. An object becomes
+unreachable once it is no longer referenced from the thread pool, but is a
+member of an object reference circle. Unreachable objects are a problem, as
+they can cause resource leaks. A desired strategy is to keep
+<VAR>Unr</VAR><SUB><VAR>t</VAR></SUB> empty at all times.</P>
+
+<P>Concepts from different language bindings map to the model's abstractions in
+different ways. Two prototypical languages are C++ (providing constructors and
+destructors of objects, but no garbage collection) and Java (providing
+constructors and finalizers of objects, with automatic garbage collection). To
+implement the UNO object life cycle model, the C++ language binding uses
+reference counting for both internal and external (bridged) objects. The Java
+language binding relies on garbage collection for internal objects, and uses
+garbage collection together with reference counting for external (bridged)
+objects.</P>
+
+<P>For C++, the relation is as follows. Calling the constructor of an object
+coincides with the object's transition from immaterial to active. After an
+object's transition from active to done, the destructor of that object will
+eventually be called. The destructor is called immediately if the object is
+only referenced locally, but it can be delayed arbitrarily if the object is
+referenced externally (over a bridge). Unreachable objects cause memory leaks,
+as their destructors are never called.</P>
+
+<P>For Java, the relation is slightly different. Again, calling the constructor
+of an object coincides with the object's transition from immaterial to active.
+After an object's transition from active to done, the finalizer of that object
+will eventually be called. For an unreachable object, the finalizer will
+eventually be called if the object is only referenced locally; the finalizer
+will not be called (and the object will cause a memory leak) if the object is
+referenced externally (over a bridge).</P>
+
+<P>This has two implications:</P>
+<OL>
+ <LI>Object reference circles have to be avoided, as they can cause objects
+ to become unreachable.</LI>
+
+ <LI>Neither the C++ destructor, nor the Java finalizer of an object are good
+ places to release any resources held by an object, as calling the destructor
+ or finalizer can be delayed arbitrarily.</LI>
+</OL>
+
+<H1>Application</H1>
+
+<P>There are various strategies how to avoid or break object reference circles,
+and how to make objects release resources in a timely fashion.</P>
+
+<H2>Object Ownership</H2>
+
+<P>One strategy to cope with object reference circles is to allow them, but to
+ensure that they are broken before the involved objects become unreachable.
+Lets assume that {<VAR>o</VAR><SUB>1</SUB>, …,
+<VAR>o</VAR><SUB><VAR>n</VAR></SUB>}, <VAR>n</VAR> ≥ 1, form an object
+reference circle. Exactly one of the objects in the circle is required to have
+a so-called <DFN>owner</DFN> <VAR>o</VAR>′ ∉
+{<VAR>o</VAR><SUB>1</SUB>, …, <VAR>o</VAR><SUB><VAR>n</VAR></SUB>};
+assume that <VAR>o</VAR>′ is the owner of <VAR>o</VAR><SUB>1</SUB>.
+As long as there are <EM>any</EM> references to the circle (from objects outside
+the circle, or from the thread pool), it is required that <VAR>o</VAR>′
+has a reference to <VAR>o</VAR><SUB>1</SUB>.</P>
+
+<P>Whenever the reference from the owner <VAR>o</VAR>′ to
+<VAR>o</VAR><SUB>1</SUB> is the only outside reference to the circle, there is a
+choice. Either, the owner decides to keep the circle active, so that other
+outside references to the circle can be made in the future. Or, the owner
+decides to be done with the circle. In that case, <VAR>o</VAR>′ must
+ensure that the circle does not become unreachable when it cuts its last outside
+reference to <VAR>o</VAR><SUB>1</SUB>. The easiest solution is that
+<VAR>o</VAR>′ tells <VAR>o</VAR><SUB>1</SUB> to break the circle, by
+clearing all references from <VAR>o</VAR><SUB>1</SUB> to any of
+{<VAR>o</VAR><SUB>1</SUB>, …, <VAR>o</VAR><SUB><VAR>n</VAR></SUB>}. Note
+that this only works if the circle is sufficiently simple, i.e., if removing the
+references from <VAR>o</VAR><SUB>1</SUB> does not introduce any new (smaller)
+object reference circles.</P>
+
+<P>There are two difficulties with this approach:</P>
+<OL>
+ <LI>The owner has to notice when it has the only outside reference to the
+ circle, so that it can decide whether to keep the circle active or to be
+ done with it.</LI>
+
+ <LI>When the owner tells the circle to break, it has to be ensured that the
+ chosen algorithm causes no objects to become unreachable (by introducing any
+ smaller object reference circles).</LI>
+</OL>
+
+<H2>Components</H2>
+
+<P>The approach of <CODE>com.sun.star.lang.XComponent</CODE> is an adaptation of
+the object ownership strategy, that tries to avoid the two difficulties
+mentioned above.</P>
+
+<P>First, the owned object <VAR>o</VAR><SUB>1</SUB> (implementing
+<CODE>com.sun.star.lang.XComponent</CODE>) has a special <DFN>disposed</DFN>
+state (to which it transitions when the owner calls the <CODE>dispose</CODE>
+method). In that state, it is still active, but behaves more or less as if it
+was done. This allows the owner to initiate breaking the circle even while
+there are still other outside references to it. Via those other references,
+<VAR>o</VAR><SUB>1</SUB> can still be reached, but it will be in its disposed
+state.</P>
+
+<P>That way, the owner does not need to notice exactly when it has the only
+outside reference to the circle. Of course, users
+of <VAR>o</VAR><SUB>1</SUB> now have to cope with the disposed state.
+Generally, it should still be ensured that there is as little access as possible
+to the object after it has been disposed.</P>
+
+<P>Second, the <CODE>XComponent</CODE> approach is designed for simple
+(subject–observer) patterns of object reference circles, where
+<VAR>o</VAR><SUB>1</SUB> (the <DFN>subject</DFN>) has a reference to each of
+{<VAR>o</VAR><SUB>2</SUB>, …, <VAR>o</VAR><SUB><VAR>n</VAR></SUB>} (the
+<DFN>observers</DFN>), and each of the observers has a reference to the subject.
+To break such a circle without introducing any new circles, it suffices to clear
+all the references from the subject to the observers, for example.</P>
+
+<H2>Weak References</H2>
+
+<P>The combination of <CODE>com.sun.star.uno.XWeak</CODE>/<!--
+--><CODE>XAdapter</CODE>/<CODE>XReference</CODE> allows to have weak references
+to objects. As long as the weakly referenced object is active,
+<CODE>XAdapter</CODE>'s <CODE>queryAdapted</CODE> returns a (true) reference to
+the object. Once the weakly referenced object is done or unreachable,
+<CODE>queryAdapted</CODE> returns either a (true) reference to the object (thus
+effectively resurrecting the object), or a null reference. Weak references can
+be used to avoid creating object reference circles, by replacing sufficiently
+many (true) references with weak references.</P>
+
+<P><EM>It has to be further investigated how weak references fit in with the UNO
+object life cycle model, and the object ownership and <CODE>XComponent</CODE>
+strategies presented above.</EM></P>
+
+<H2>Disposing</H2>
+
+<P>As explained, a UNO object that has acquired any references should release
+them well before the language binding has determined that the object is no
+longer active (e.g., via a destructor or finalizer call), as there can be an
+arbitrarily long time span between the object becoming done or unreachable, and
+the destructor or finalizer being called. The UNO object should offer an
+explicit mechanism to release its resources, probably as a method of a supported
+interface.</P>
+
+<P>This is similar to the object ownership/<CODE>XComponent</CODE> strategy, in
+that in both cases some entity has to determine when to dispose an object
+(typically, a method named <CODE>dispose</CODE>, or similar, is used in both
+cases: in the <CODE>XComponent</CODE> case, disposing is used to break object
+reference circles; in this case, disposing is used to make an object release its
+resources). A theoretically appealing solution would be that the last user of
+an object holding resources calls <CODE>dispose</CODE> once it has finished
+using it, but it can be difficult to determine when this condition occurs.
+Again, a simple solution is to introduce a special <DFN>disposed</DFN> state for
+the object holding the resources. Then, some entity can call
+<CODE>dispose</CODE> on the object without knowing exactly whether there are
+still other references to it (but those other references then have to cope with
+the object being in disposed state).</P>
+
+<TABLE WIDTH="100%" BORDER="0" CELLSPACING="0" CELLPADDING="4">
+ <TR><TD BGCOLOR="#666699">
+ <P><FONT COLOR="White">Author:
+ <A HREF="mailto:stephan.bergmann@sun.com"><FONT COLOR="White">Stephan
+ Bergmann</FONT></A> (last modification $Date: 2004/10/29 07:16:43 $).
+ Copyright 2003 <A HREF="http://www.openoffice.org"><FONT
+ COLOR="White">OpenOffice.org</FONT></A> Foundation. All rights
+ reserved.</FONT></P>
+ </TD></TR>
+</TABLE>
+
+</body>
+</HTML>
diff --git a/content/udk/common/man/module_description.html b/content/udk/common/man/module_description.html
new file mode 100644
index 0000000..7635dbd
--- /dev/null
+++ b/content/udk/common/man/module_description.html
@@ -0,0 +1,309 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+<head>
+ <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=iso-8859-1">
+ <TITLE>Module Description</TITLE>
+ <META NAME="GENERATOR" CONTENT="StarOffice/5.2 (Win32)">
+ <META NAME="CLASSIFICATION" CONTENT="Module Description">
+ <META NAME="KEYWORDS" CONTENT="UNO,Module,Component,Description">
+</head>
+<body LINK="#444488" VLINK="#444488" BGCOLOR="#eeeeff">
+<TABLE WIDTH=100% BORDER=0 CELLPADDING=4 CELLSPACING=0 STYLE="page-break-before: always">
+ <COL WIDTH=75>
+ <TR>
+ <TD BGCOLOR="#666699">
+ <H1 ALIGN=CENTER STYLE="margin-top: 0cm; text-decoration: none"><A HREF="http://www.openoffice.org/"><IMG SRC="../../images/open_office_org_logo.gif" NAME="Grafik1" ALT="OpenOffice" ALIGN=RIGHT WIDTH=109 HEIGHT=54 BORDER=0></A><FONT COLOR="#ffffff"><FONT SIZE=6>Module Description</FONT></FONT></H1>
+ </TD>
+ </TR>
+</TABLE>
+<HR SIZE=3 noshade>
+<TABLE WIDTH=100% BORDER=0 CELLPADDING=4 CELLSPACING=0 STYLE="page-break-before: always">
+ <COL WIDTH=75*>
+ <COL WIDTH=130*>
+ <COL WIDTH=51*>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3 ALIGN=LEFT STYLE="margin-top: 0cm; text-decoration: none"><FONT COLOR="#ffffff"><FONT SIZE=4>Contents</FONT></FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <A HREF="#Overview">Overview</A><BR>
+ <A HREF="#Description">Description of module-description.dtd</A><BR>
+ <A HREF="#Integration_of_the_component_description_in_the_component">Integration
+ of the module description in the component</A><BR>
+ <A HREF="#Example">Example</A><BR>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3 ALIGN=LEFT STYLE="margin-top: 0cm; text-decoration: none"><A NAME="Overview"></A>
+ <FONT COLOR="#ffffff"><FONT SIZE=4>Overview</FONT></FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+
+ <P>A module description provides detailed information about the module and
+ its supported components, which is accessible in different manners. The included
+ description is available by reading directly, by generating a short html-description, or by
+ making an environment check for supported components to check if all
+ needed types and services are available in the environment where they will be
+ used. This environment check could take place during registration/installation
+ or during a separate consistency check for a component. </P>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Description"></A><FONT COLOR="#ffffff">Description of
+ module-description.dtd</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P><CODE>module-description.dtd</CODE></P>
+
+ <P><CODE><?xml version="1.0" encoding="UTF-8"?><BR>
+ <!-- ... --><BR>
+ </CODE></P>
+ <P><CODE><!ENTITY % component-description-optional "reference-docu|service-dependency|type"><br>
+ <!ENTITY % module-description-optional "project-build-dependency|runtime-module-dependency|(%component-description-optional;)"><br>
+ <!ELEMENT module-description (module-name,component-description+,(%module-description-optional;)*)>
+ <BR>
+ <!ELEMENT component-description (author,name,description,loader-name,supported-service+,(%component-description-optional;)*)
+ ><BR>
+ <BR>
+ <!ELEMENT author (#PCDATA)><br>
+ <!ELEMENT name (#PCDATA)><BR>
+ <!ELEMENT description (#PCDATA)><br>
+ <BR>
+ <!ELEMENT reference-docu EMPTY><br>
+ <!ATTLIST reference-doc<br>
+ xmlns:xlink CDATA #FIXED "http://www.w3.org/1999/xlink/Namespace"<br>
+ xlink:type (simple) #FIXED "simple"<br>
+ xlink:href CDATA #REQUIRED<br>
+ xlink:role NMTOKEN #IMPLIED<br>
+ xlink:title CDATA #IMPLIED ><br>
+ <br>
+ <!ELEMENT module-name (#PCDATA)><BR>
+ <!ELEMENT loader-name (#PCDATA)><BR>
+ <!ELEMENT supported-service (#PCDATA)><BR>
+ <!ELEMENT service-dependency (#PCDATA)><BR>
+ <!ELEMENT project-build-dependency (#PCDATA)><BR>
+ <!ELEMENT runtime-module-dependency (#PCDATA)><BR>
+ <!ELEMENT language (#PCDATA)><BR>
+ <!ELEMENT status EMPTY ><BR>
+ <!ATTLIST status value (under_construction | alpha | beta | final)
+ #REQUIRED><BR>
+ <!ELEMENT type (#PCDATA)></CODE></P>
+ <br>
+ <table width=95% border=1 cellpadding=5 cellspacing=3>
+ <tr valign=TOP>
+ <td width=23%>author</td>
+ <td width=77%>The name of the person who has implemented the component</td>
+ </tr>
+ <tr valign=TOP>
+ <td width=23%>name</td>
+ <td width=77%>
+ <p>The implementation name of a component. <br>
+ (e.g., com.sun.star.comp.stoc.ORegistryServiceManager)</p>
+ </td>
+ </tr>
+ <tr valign=TOP>
+ <td width=23%>description</td>
+ <td width=77%>
+ <p>A short description which should be understandable to all people in
+ the development process.</p>
+ </td>
+ </tr>
+ <tr valign=TOP>
+ <td width=23%>reference-docu</td>
+ <td width=77%>specify an xlink to further documentation.</td>
+ </tr>
+ <tr valign=TOP>
+ <td width=23%>module-name</td>
+ <td width=77%>
+ <p>The name of a shared library without the system prefix (lib) or
+ postfix (.so, .dll, ...)<br>
+ (e.g., smgr). An executable name. A Java class file name or the
+ JAR name.</p>
+ </td>
+ </tr>
+ <tr valign=TOP>
+ <td width=23%>loader-name</td>
+ <td width=77%>
+ <p>The service name of the loader, which should be used to load the component.<br>
+ (e.g., com.sun.star.loader.SharedLibrary)</p>
+ </td>
+ </tr>
+ <tr valign=TOP>
+ <td width=23%>supported-service</td>
+ <td width=77%>
+ <p>All services supported by this component.<br>
+ (e.g., com.sun.star.registry.SimpleRegistry)</p>
+ </td>
+ </tr>
+ <tr valign=TOP>
+ <td width=23%>service-dependency</td>
+ <td width=77%>
+ <p>All services need this implementation.<br>
+ (e.g., com.sun.star.lang.RegistryServiceManager (very often the
+ service manager component is used) )</p>
+ </td>
+ </tr>
+ <tr valign=TOP>
+ <td width=23%>project-build-dependency</td>
+ <td width=77%>
+ <p>All projects which are necessary.<br>
+ (e.g., cppuhelper, cppu, vos, sal, stl)</p>
+ </td>
+ </tr>
+ <tr valign=TOP>
+ <td width=23%>runtime-module-dependency</td>
+ <td width=77%>
+ <p>All projects which are used at runtime <br>
+ (e.g., cppu1, vos1$(COM), sal1)</p>
+ </td>
+ </tr>
+ <tr valign=TOP>
+ <td width=23%>language</td>
+ <td width=77%>
+ <p>The language in which the component is implemented.<br>
+ (e.g., C++)</p>
+ </td>
+ </tr>
+ <tr valign=TOP>
+ <td width=23%>status</td>
+ <td width=77%>
+ <p>The implementation state of the component.<br>
+ (under construction, alpha, beta, or final)</p>
+ </td>
+ </tr>
+ <tr valign=TOP>
+ <td width=23%>type</td>
+ <td width=77%>
+ <p>Which type descriptions are necessary to enable communication
+ with other environments. To ensure that the bridges can create proxies
+ and stubs, they must get the type description of the used types.<br>
+ The special term "comprehensive" means that all type descriptions
+ are built into the component.<br>
+ The type descriptions must be installed in the type repository (applicat.rdb).</p>
+ </td>
+ </tr>
+ </table>
+ <P><i>*$(COM) is the extension of the C++ compiler.</i><br>
+ <i>*$(SUPDCP) is the extension of a module which depends on an SUPD and the
+ platform.</i></P>
+ <p>All components written in C++ need the bridge library from uno to C++ for
+ scripting or remote communication. These are the <i>msci_uno.dll</i> with
+ the MSC4.2 and the MSC6.0; and the <i>libsunpro5_uno.so</i> library with the
+ SunPro 5.0 compiler.</p>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+
+ <H3><A NAME="Integration_of_the_component_description_in_the_component"></A>
+ <FONT COLOR="#ffffff">Integration of the module description in the module(component)</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+
+ <P>Normally, the module description should also be available by calling the
+ module itself. In case of an implementation as a shared library, the shared
+ library should export a C-function which provides this xml description
+ as a return value of type <I>sal_Char*</I>. This function could be generated
+ from the xml description by using the tool <A HREF="tools.html#xml2cmp">xml2cmp</A>.
+ The generated source file must be built with the component and the C-function
+ <CODE>component_getDescriptionFunc</CODE> must be exported.</P>
+ <P>Example for a simple registry component:</P>
+ <P><CODE><A HREF="tools.html#xml2cmp">xml2cmp</A>
+ -func simreg_desc.cxx simreg.xml</CODE>
+ </P>
+ <br>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100% BGCOLOR="#666699">
+ <H3><A NAME="Example"></A><FONT COLOR="#ffffff">Example:</FONT></H3>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <P>Description for the simple registry component, simreg.xml:
+ </P>
+
+ <P><CODE><?xml version='1.0' encoding="UTF-8"?><BR>
+ <!DOCTYPE module-description PUBLIC "-//W3C//DTD HTML 3.2//EN"
+ "module-description.dtd"><BR>
+ <BR>
+ <module-description xmlns:xlink=""http://www.w3.org/1999/xlink"><br>
+ <module-name> simreg </module-name><br>
+ <component-description><br>
+ <br>
+ <author> Juergen Schmidt </author><BR>
+ <name> com.sun.star.comp.stoc.SimpleRegistry </name><BR>
+ <BR>
+ <description><BR>
+ This component provides access to a simple hierarchical registry. The registry
+ based on one registry file.<BR>
+ </description><BR>
+ <BR>
+ <loader-name> com.sun.star.loader.SharedLibrary </loader-name><BR>
+ <language> c++ </language><br>
+ <status value="final"/><br>
+ </CODE></P>
+ <P><CODE><supported-service> com.sun.star.registry.SimpleRegistry
+ </supported-service><BR>
+ </CODE></P>
+ <P><CODE><type> com.sun.star.lang.XTypeProvider </type><br>
+ <type> com.sun.star.lang.XServiceInfo </type><br>
+ <type> com.sun.star.lang.XSingleServiceFactory </type><br>
+ <type> com.sun.star.lang.XMultiServiceFactory </type><br>
+ <type> com.sun.star.registry.XSimpleRegistry </type><br>
+ <type> com.sun.star.registry.XRegistryKey </type><br>
+ <type> com.sun.star.uno.XAggregation </type><br>
+ <type> com.sun.star.uno.XWeak </type><br>
+ <type> com.sun.star.uno.TypeClass </type><br>
+ </CODE></P>
+ <P><CODE></component-description></CODE></P>
+ <P><CODE> <project-build-dependency> cppuhelper </project-build-dependency><BR>
+ <project-build-dependency> cppu </project-build-dependency><BR>
+ <project-build-dependency> registry </project-build-dependency><BR>
+ <project-build-dependency> store </project-build-dependency><BR>
+ <project-build-dependency> vos </project-build-dependency><BR>
+ <project-build-dependency> sal </project-build-dependency><BR>
+ <BR>
+ <runtime-module-dependency> cppuhelper </runtime-module-dependency><BR>
+ <runtime-module-dependency> cppu1 </runtime-module-dependency><BR>
+ <runtime-module-dependency> reg1 </runtime-module-dependency><BR>
+ <runtime-module-dependency> store1 </runtime-module-dependency><BR>
+ <runtime-module-dependency> vos1$(COM) </runtime-module-dependency><BR>
+ <runtime-module-dependency> sal1 </runtime-module-dependency><BR>
+ <BR>
+ </module-description> </CODE> </P>
+ </TD>
+ </TR>
+ <TR>
+ <TD COLSPAN=3 WIDTH=100%>
+ <HR SIZE=1 noshade>
+ </TD>
+ </TR>
+ <TR>
+ <TD WIDTH=50% BGCOLOR="#666699">
+
... 283453 lines suppressed ...