incubator-ooo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ksch...@apache.org
Subject svn commit: r1206895 [1/12] - in /incubator/ooo/ooo-site/trunk/content/udk/common: ./ man/ man/concept/ man/draft/ man/draft/scripting/ man/draft/scripting/DesignDoc/ man/images/ man/spec/ man/tasks/ man/tutorial/
Date Sun, 27 Nov 2011 22:50:08 GMT
Author: kschenk
Date: Sun Nov 27 22:49:46 2011
New Revision: 1206895

URL: http://svn.apache.org/viewvc?rev=1206895&view=rev
Log:
kls --added usk/common


Added:
    incubator/ooo/ooo-site/trunk/content/udk/common/
    incubator/ooo/ooo-site/trunk/content/udk/common/man/
    incubator/ooo/ooo-site/trunk/content/udk/common/man/apicppclasses.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/binspec.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/bridge.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/componentmodel.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/componentnames.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/
    incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/default_bootstrapping.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/micro_deployment.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/streams.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/string_invest.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/uno_contexts.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/uno_corba.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/uno_default_bootstrapping.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/uno_langbind.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/uno_security.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/unointro.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/library_unloading.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ArchDoc.20020618.sxw   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/BindException.idl
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/BindingUI.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/BindingActions.dia   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/BindingSequence.png   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/SO-IDE-debug.dia   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/ScriptInfo.idl
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/ScriptInvocationClassDiagram.dia
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/ScriptResolution.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/ScriptURI.idl
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/Source-Edit.png   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/StorageServiceClassDiagram.png   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/XBinding.idl
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/XScriptImpl.idl
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/XScriptInfo.idl
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/addassoc.png   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/index.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/DesignDoc/remove.dia   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/MethodInvokeException.idl
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ProblemsIssues.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ScriptEngine.idl
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ScriptRegisterException.idl
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ScriptStartedEvent.idl
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ScriptWP.sxw   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/Services-and-interfaces.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ThreadingSoln.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/XModules.idl
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/XMonitorListener.idl
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/arch.txt   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/archdiag.pdf   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/basic-storage.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/build-script.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/ide.txt   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/draft/scripting/index.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/idl.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/idl_syntax.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/JScriptWP_classes.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/OO-NetBeans-Dynamic-fs.jpg   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/OO-NetBeans-Dynamic-serial.jpg   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/aggregation.jpg   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/binaryspec.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/component_environments.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/context_example1.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/context_example2.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/context_propagation.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/iiopbridge.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/jbu_draft_moduleadmin.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/passing_interface_reference_acquire_in_advance.jpg   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/passing_interface_reference_corba_uno.jpg   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/passing_interface_reference_uno_uno.jpg   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/pipe_inheritance.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/sec_dynamic.jpg   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/sec_interprocess.jpg   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/sec_overview.jpg   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/sec_resource.jpg   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/stream_active_sink.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/stream_chaining.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/stream_connected_chain.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/stream_connected_pipe.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/stream_datacontrol.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/stream_interfaces.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/stream_piping.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/stream_read.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/stream_read_and_convert.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/stream_source_sink.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/uno-url.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/uno-url.sxd   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/images/uno_soap.gif   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/lifecycle.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/module_description.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/names.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/spec/
    incubator/ooo/ooo-site/trunk/content/udk/common/man/spec/assemblyversioning.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/spec/assemblyversioninghistory.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/spec/com_lang_spec.htm
    incubator/ooo/ooo-site/trunk/content/udk/common/man/spec/connection_services.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/spec/javavendorextension.sxw   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/spec/library_unloading.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/spec/ole_bridge.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/spec/remotebridge.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/spec/transparentofficecomponents.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/spec/uno-url.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/spec/urp.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/tasks/
    incubator/ooo/ooo-site/trunk/content/udk/common/man/tasks/api_docu_review.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/tasks/apitests.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/tasks/tasks.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/tools.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/tutorial/
    incubator/ooo/ooo-site/trunk/content/udk/common/man/tutorial/office_automation.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/tutorial/uno_registries.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/tutorial/writerdemo.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/typenames.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/typesystem.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/uno.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/uno_components.html   (with props)
    incubator/ooo/ooo-site/trunk/content/udk/common/man/uno_the_idea.html   (with props)

Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/apicppclasses.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/apicppclasses.html?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/apicppclasses.html (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/apicppclasses.html Sun Nov 27 22:49:46 2011
@@ -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&nbsp;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&nbsp;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&nbsp;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&nbsp;4 plus recursive application of point&nbsp;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&nbsp;4
+    plus recursive application of point&nbsp;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&nbsp;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&nbsp;1</code>
+    variant symbols.</li>
+
+    <li>For each destructor that shall be available outside the dynamic library,
+    export any corresponding plain and <code>#Nvariant&nbsp;1</code> variant
+    symbols.</li>
+
+    <li>For each class that is used outside the dynamic library in ways covered
+    by point&nbsp;4 plus recursive application of point&nbsp;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>

Propchange: incubator/ooo/ooo-site/trunk/content/udk/common/man/apicppclasses.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/binspec.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/binspec.html?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/binspec.html (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/binspec.html Sun Nov 27 22:49:46 2011
@@ -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&ouml;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>

Propchange: incubator/ooo/ooo-site/trunk/content/udk/common/man/binspec.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/bridge.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/bridge.html?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/bridge.html (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/bridge.html Sun Nov 27 22:49:46 2011
@@ -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>

Propchange: incubator/ooo/ooo-site/trunk/content/udk/common/man/bridge.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/componentmodel.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/componentmodel.html?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/componentmodel.html (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/componentmodel.html Sun Nov 27 22:49:46 2011
@@ -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 &ldquo;component&rdquo; 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&nbsp;<var>N</var>,
+    compute a service instantiation name&nbsp;<var>N</var>&prime; from it, and
+    expect to obtain a component instance with a certain component client
+    interface when passing <var>N</var>&prime; to the component manager.</li>
+</ul>
+
+<p>A <dfn>component client interface</dfn> is a set of UNO interface types
+(referenced by their&mdash;globally unique&mdash;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&mdash;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>

Propchange: incubator/ooo/ooo-site/trunk/content/udk/common/man/componentmodel.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/componentnames.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/componentnames.html?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/componentnames.html (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/componentnames.html Sun Nov 27 22:49:46 2011
@@ -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
+&ldquo;<CODE>.uno</CODE>&rdquo; and the platform-specific extension
+(&ldquo;<CODE>.so</CODE>&rdquo;, &ldquo;<CODE>.dll</CODE>&rdquo;,
+&ldquo;<CODE>.dylib</CODE>&rdquo;, 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>&ndash;<CODE>9</CODE> <CODE>0</CODE>&ndash;<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 &ldquo;<CODE>.so</CODE>&rdquo;, 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&mdash;the few functions
+<CODE>component_getFactory</CODE> etc.&mdash;never changes).</P>
+
+<P>The &ldquo;<CODE>.uno</CODE>&rdquo; 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 &ldquo;<CODE>.uno</CODE>&rdquo; in its name.
+Therefore, no tool should build assumptions on whether a shared library name
+contains &ldquo;<CODE>.uno</CODE>&rdquo; 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
+&ldquo;<CODE>.uno</CODE>&rdquo; 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
+&ldquo;<CODE>.uno</CODE>&rdquo; (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 &ldquo;Extending
+        Published Services with Optional Interfaces Considered Harmful&rdquo;
+        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>

Propchange: incubator/ooo/ooo-site/trunk/content/udk/common/man/componentnames.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/default_bootstrapping.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/default_bootstrapping.html?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/default_bootstrapping.html (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/default_bootstrapping.html Sun Nov 27 22:49:46 2011
@@ -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>

Propchange: incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/default_bootstrapping.html
------------------------------------------------------------------------------
    svn:eol-style = native

Added: incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/micro_deployment.html
URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/micro_deployment.html?rev=1206895&view=auto
==============================================================================
--- incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/micro_deployment.html (added)
+++ incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/micro_deployment.html Sun Nov 27 22:49:46 2011
@@ -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' &gt; 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' &gt; 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>
+

Propchange: incubator/ooo/ooo-site/trunk/content/udk/common/man/concept/micro_deployment.html
------------------------------------------------------------------------------
    svn:eol-style = native



Mime
View raw message