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/01 22:16:46 UTC
[openoffice-org] branch main updated (a44b02c -> e4fdea0)
This is an automated email from the ASF dual-hosted git repository.
wave pushed a change to branch main
in repository https://gitbox.apache.org/repos/asf/openoffice-org.git.
from a44b02c Migration of awards html content
new 976c5ca Migration of white_papers assets
new e4fdea0 Migration of white_papers html content
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
.../tech_overview/staroffice_layers.gif | Bin 0 -> 11932 bytes
.../white_papers/tech_overview/tech_overview.pdf | Bin 0 -> 110527 bytes
.../white_papers/tech_overview/tech_overview.sdw | Bin 0 -> 251392 bytes
content/white_papers/OOo_project/OOo_project.html | 52 +
.../white_papers/OOo_project/contributions.html | 51 +
content/white_papers/OOo_project/introduction.html | 114 ++
.../OOo_project/openofficefoundation.html | 38 +
content/white_papers/OOo_project/preface.html | 42 +
content/white_papers/OOo_project/strategy.html | 137 ++
content/white_papers/index.html | 30 +
.../white_papers/tech_overview/tech_overview.html | 1661 ++++++++++++++++++++
11 files changed, 2125 insertions(+)
create mode 100644 assets/white_papers/tech_overview/staroffice_layers.gif
create mode 100644 assets/white_papers/tech_overview/tech_overview.pdf
create mode 100644 assets/white_papers/tech_overview/tech_overview.sdw
create mode 100644 content/white_papers/OOo_project/OOo_project.html
create mode 100644 content/white_papers/OOo_project/contributions.html
create mode 100644 content/white_papers/OOo_project/introduction.html
create mode 100644 content/white_papers/OOo_project/openofficefoundation.html
create mode 100644 content/white_papers/OOo_project/preface.html
create mode 100644 content/white_papers/OOo_project/strategy.html
create mode 100755 content/white_papers/index.html
create mode 100644 content/white_papers/tech_overview/tech_overview.html
[openoffice-org] 01/02: Migration of white_papers assets
Posted by wa...@apache.org.
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 976c5cacd9634b02d7da57c03626d43b656c6157
Author: Dave Fisher <da...@davefisher.tech>
AuthorDate: Sun Nov 1 14:16:41 2020 -0800
Migration of white_papers assets
---
.../white_papers/tech_overview/staroffice_layers.gif | Bin 0 -> 11932 bytes
assets/white_papers/tech_overview/tech_overview.pdf | Bin 0 -> 110527 bytes
assets/white_papers/tech_overview/tech_overview.sdw | Bin 0 -> 251392 bytes
3 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/assets/white_papers/tech_overview/staroffice_layers.gif b/assets/white_papers/tech_overview/staroffice_layers.gif
new file mode 100644
index 0000000..df818fa
Binary files /dev/null and b/assets/white_papers/tech_overview/staroffice_layers.gif differ
diff --git a/assets/white_papers/tech_overview/tech_overview.pdf b/assets/white_papers/tech_overview/tech_overview.pdf
new file mode 100644
index 0000000..4b18ad9
Binary files /dev/null and b/assets/white_papers/tech_overview/tech_overview.pdf differ
diff --git a/assets/white_papers/tech_overview/tech_overview.sdw b/assets/white_papers/tech_overview/tech_overview.sdw
new file mode 100644
index 0000000..33069d4
Binary files /dev/null and b/assets/white_papers/tech_overview/tech_overview.sdw differ
[openoffice-org] 02/02: Migration of white_papers html content
Posted by wa...@apache.org.
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 e4fdea0fda112017f823d76136e782f120556b8e
Author: Dave Fisher <da...@davefisher.tech>
AuthorDate: Sun Nov 1 14:16:41 2020 -0800
Migration of white_papers html content
---
content/white_papers/OOo_project/OOo_project.html | 52 +
.../white_papers/OOo_project/contributions.html | 51 +
content/white_papers/OOo_project/introduction.html | 114 ++
.../OOo_project/openofficefoundation.html | 38 +
content/white_papers/OOo_project/preface.html | 42 +
content/white_papers/OOo_project/strategy.html | 137 ++
content/white_papers/index.html | 30 +
.../white_papers/tech_overview/tech_overview.html | 1661 ++++++++++++++++++++
8 files changed, 2125 insertions(+)
diff --git a/content/white_papers/OOo_project/OOo_project.html b/content/white_papers/OOo_project/OOo_project.html
new file mode 100644
index 0000000..6ebd639
--- /dev/null
+++ b/content/white_papers/OOo_project/OOo_project.html
@@ -0,0 +1,52 @@
+<html><head>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+
+<h2>The OpenOffice.org Project
+</h2><br>
+<P><B>Foundations of Office Productivity in a Networked Age</b>
+
+<ul>
+ <a href="preface.html">Preface</a><BR>
+ <a href="preface.html#history">History</a>
+ <BR>
+ <BR>
+ <a href="introduction.html">Introduction</a><BR>
+ <a href="introduction.html#what_is">What
+ is OpenOffice.org?</a><BR>
+ <a href="introduction.html#why_is">Why is
+ Sun Microsystems doing this?</a><BR>
+ <a href="introduction.html#strategic">Strategic
+ Background</a><BR>
+ <a href="introduction.html#office_prod">Office
+ Productivity for a Networked Age</a><BR>
+ <a href="introduction.html#future_prod">Future
+ StarOffice Productivity Suite for Sun Microsystems</a> <BR>
+ <BR>
+ <a href="strategy.html">Licensing Strategy</a><BR>
+ <a href="strategy.html#dual_license">The
+ Dual-License Strategy</a><BR>
+ <a href="strategy.html#specifics">Specifics
+ of the OpenOffice.org License Strategy</a><BR>
+ <a href="strategy.html#dual_licensing_standards">Dual
+ Licensing and Standards Compatibility</a><BR>
+ <a href="strategy.html#specification">Specification
+ of Standard Versions</a><BR>
+ <a href="strategy.html#staroffice">StarOffice
+ Brand Usage</a> <BR>
+ <BR>
+ <a href="contributions.html">Making Contributions to the OpenOffice.org
+ Project</a><BR>
+ 1. <a href="contributions.html#dual_license">Dual-License
+ Usage</a><BR>
+ 2. <a href="contributions.html#copyright">Copyright
+ Assignment</a> <BR>
+ <BR>
+ <a href="openofficefoundation.html">The OpenOffice.org Foundation</a><BR>
+ <a href="openofficefoundation.html#standards_process">OpenOffice.org
+ Standards Process</a>
+</ul>
+</body>
+</html>
+
diff --git a/content/white_papers/OOo_project/contributions.html b/content/white_papers/OOo_project/contributions.html
new file mode 100644
index 0000000..42f01cb
--- /dev/null
+++ b/content/white_papers/OOo_project/contributions.html
@@ -0,0 +1,51 @@
+<!DOCTYPE html>
+<html><head>
+<title>Making Contributions to the OpenOffice.org Project</title>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+<h2>The OpenOffice.org Project</h2>
+<BR><BR>
+
+<h4>Making Contributions to the OpenOffice.org Project</h4>
+
+<p>
+The use of the dual-license scheme is both open and beneficial for the development,
+access, distribution, and compatibility of OpenOffice.org technologies and
+standards. For contributions of technology from the open communities, it is
+necessary to use the identical mechanisms and terms already in use by the
+OpenOffice.org project. Specifically, the following two requirements regarding
+the terms under which such contributions are made must be met in order to allow a
+contribution to be accepted into the OpenOffice.org Project technology base.
+<BR><BR><BR>
+<A NAME=duel_license><B>1. Dual-License Usage</B></A>
+<BR>
+The contributing individual or organization should issue their contributions for
+inclusion within the OpenOffice.org project technology base using the dual-license
+mechanism of GPL/LGPL + OpenOffice.org SISSL, without modification to the
+license terms and conditions. Contributions that cannot be made available under this
+dual-licensing mechanism will be incompatible with the required open access to the
+OpenOffice.org technology, and thus cannot be incorporated into the OpenOffice.org
+technology base.
+Such dual-licensing practices are now common within the open source communities.
+Examples include technology projects such as Perl (Artistic + GPL) Mozilla™ (MPL + NPL), and various others.
+
+<BR><BR><BR>
+<A NAME=copyright><B>2. Copyright Assignment</B></A>
+<BR>
+To enable Sun Microsystems to effectively provide license management, enforce
+legal compliance, and issue technology adequately to commercial licensees,
+all contributions being made for inclusion in the OpenOffice.org technology base
+must make a copyright assignment of the source code to Sun Microsystems, Inc.
+This follows the same principals as recommended by the Free Software
+Foundation regarding copyright assignment for contributions to the GNU Project.
+Copyright assignment is a common requirement within open source projects for
+legal indemnification management and for flexibility of second licensing.
+<BR><BR>
+
+<P ALIGN=right VALIGN=bottom><A HREF="strategy.html">back</A> <A HREF="openofficefoundation.html">next</A> </P>
+
+
+</body>
+</html>
+
diff --git a/content/white_papers/OOo_project/introduction.html b/content/white_papers/OOo_project/introduction.html
new file mode 100644
index 0000000..37430dd
--- /dev/null
+++ b/content/white_papers/OOo_project/introduction.html
@@ -0,0 +1,114 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<title>The OpenOffice.org Project</title>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+</head>
+<body>
+
+
+<h2>The OpenOffice.org Project
+</h2> <br>
+ <br>
+<p><b>Introduction</b>
+
+<br>
+The OpenOffice.org project is an historic development for the open systems world
+and the open source movement. In a networked age, the rules by which software is
+created, defined, and distributed are being redefined. Software, in essence a
+powerful form of expressing human knowledge and logic, is entering the realm of
+other free and open forms for the expression of human ideas. The pervasiveness of
+the network has been central in driving this redefinition of the qualities of software.
+The need for certain forms of software to be available in an equitable form becomes
+very apparent, especially when related to the creation, exchange, and communication
+of information. It is important to note that in recent times, some of the most
+significant forces that have influenced change in our information-centric world have
+resulted from the use of tools and formats for mechanisms such as e-mail, Web
+servers and Web browser, IRC, and even the very recent Instant Messenger service.
+All of these software-based infrastructures have shifted to be foundational in nature,
+based upon technology standards and formats available to all innovators, without
+restriction.<br><br>
+The OpenOffice.org project establishes these same freedoms for the software
+technology used for information collection commonly called office documents. As a
+result of these office document formats and the implementation of their accompanying
+software application utilities becoming foundational technologies — freely
+available to all through the OpenOffice.org project — office documents have made
+the important transition from the proprietary world to become universal,
+incorporated into the foundational network information standards. The
+OpenOffice.org project marks the beginning of an era of universality for office
+productivity documents as well as their arrival as network standard formats and
+services.
+<br><br><br>
+<a NAME=what_is><b>What is Open Office.org?</b></a>
+<br>
+OpenOffice.org is the open source project through which Sun Microsystems is
+releasing the technology that powers the globally popular StarOffice™ productivity
+suite. The OpenOffice.org project establishes the necessary facilities to make this
+open source technology available to the developer communities worldwide. Source
+code technology will be made publicly available via the Internet in both tar-ball and
+CVS formats. The project site will provide forums for direct communications and
+discussions among developers. Plus, the project site is constructed to provide a
+center for full and comprehensive information regarding all aspects of the project
+and its technology. This includes details on the technology and how it can be used as
+a basis for further innovation, for example, from API and architectural
+documentation through to planning, news, and promotional information.<br><br>
+The OpenOffice.org network hosted community can be found at <a HREF="/">
+/.</a>
+<br><br><br>
+<a NAME=why_is><b>Why is Sun Microsystems doing this?</b></a>
+<br><br>
+<a NAME=strategic><b>Strategic Background</b></a><br>Sun Microsystems was founded in 1982 upon three principles. First, that open
+systems' strategies for technology will ultimately expand the markets for
+information technology products more successfully than those derived from a
+proprietary basis. Second, that the network was to become the foundation upon
+which all computing platforms would be constructed in such an open systems
+world, expressed by Sun's visionary slogan "The Network is the Computer™". And third, the law of innovation commonly described by Bill Joy, (co-founder of Sun
+Microsystems and original leader of the seminal open source BSD project) as
+"Innovation will occur" and its corollary, "that it will occur elsewhere" requires that
+strategies must be sought to embrace the concepts of the innovators who will be
+"elsewhere" by definition.<br><br>
+Sun recognizes that all the successful software and network technologies it uses and
+develops must have these foundational principles at their core. A brief review of
+Sun's statements and actions from its beginning will show a consistency in
+developing the means to build itself upon these same principles.
+<br><br>
+<a NAME=office_prod><b>Office Productivity for a Networked Age</b></a><br>Because future computing is being designed and built with the network as its
+foundation, Sun Microsystems has been committed to the development, adoption,
+and deployment of the network-based Open Information Architecture. From the core
+of TCP/IP to e-mail, NFS™, XML, and Java™ technologies establishing the standards
+for this Open Information Architecture has always been a primary goal for
+contributing towards open systems and enabling a viable and compelling
+information computing future.<br><br>
+By 1998, it became clear that the office suite formats and utilities would need to
+become standardized and fully open definitions of the Open Information
+Architecture. The knowledge that the diverse forms of devices by which people
+would access and use the network and its computing resources would expand far
+beyond today's PC-class device meant that this would become a critical requirement.
+In August 1999, Sun acquired Star Division, Inc., the developer of a comprehensive,
+multi-platform, office productivity suite technology that was gaining momentum on
+open systems platforms. The Star Division technology offered the ideal technology
+basis and engineering talent to deliver on Sun's strategic objectives for an open
+definition of these formats and utilities. The component-based language and
+platform-neutral architecture of the StarOffice utilities were ideally suited to form
+the basis for an open office productivity suite. Prior to the acquisition, work towards
+XML-based office document file formats had also been progressing.<br><br>
+Since then, a focussed effort has been placed upon development of both the
+technologies and the details of the strategy necessary to introduce this next critical
+piece of the network-based Open Information Architecture. The launch of the
+OpenOffice.org project introduces this initiative.
+<br><br>
+<a NAME=future_prod><b>Future StarOffice Productivity Suite from Sun Microsystems</b></a><br>Sun Microsystems' engineering efforts that will deliver future versions of the
+StarOffice productivity suite will be derived directly from the OpenOffice.org
+technology base. Sun will use the single OpenOffice.org master CVS source base as
+its own engineering master source base. Thus, developers from all communities will
+be able to see Sun's development contributions on a daily basis and be able to
+become directly involved in the development of the OpenOffice.org technology as
+well as the branded StarOffice productivity suite.<br><br>
+For more detail regarding OpenOffice.org technology, a complementary white paper
+will be available that provides an in-depth overview of the component features,
+component system, XML formats, APIs, and environment enabling.
+
+<p ALIGN=right VALIGN=bottom><a HREF="preface.html">back</a> <a HREF="strategy.html">next</a> </p>
+</body>
+</html>
+
diff --git a/content/white_papers/OOo_project/openofficefoundation.html b/content/white_papers/OOo_project/openofficefoundation.html
new file mode 100644
index 0000000..4adb229
--- /dev/null
+++ b/content/white_papers/OOo_project/openofficefoundation.html
@@ -0,0 +1,38 @@
+<html><head>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+
+<h2>The OpenOffice.org Foundation</h2>
+<p><i>Last updated 2001 November 4</p>
+<BR>
+<p>The OpenOffice.org project currently does not have a foundation. Plans are in the works for creating such a foundation. The below text was composed at the project's birth and can serve as a proposal for the creation of a foundation.</p>
+<br>
+<p>The OpenOffice.org project will establish the OpenOffice.org Foundation, a
+non-profit organization that will oversee the operations, technology strategy,
+incorporation of technology contributions, and establishment of standards in
+conjunction with other standards bodies and open source projects as appropriate.
+The intention is that this foundation will be modeled after the Apache Software
+Foundation. A Steering Committee (or board) will be established with members
+from the open development community and SISSL licensees. Sun Microsystems will
+hold a minority representation in this governance structure.</p>
+<BR><BR><BR>
+<A NAME=standards_process><B>Open Office.org Standards Process</B></A>
+<BR>
+The key objectives of the OpenOffice.org project include:<UL>
+<LI TYPE=disc>Establishment of standard, open productivity, XML-based file formats and
+component application programming interfaces (APIs).
+<LI TYPE=disc>Creation of standard implementation source code for the open office productivity
+utilities that implement the APIs and utilize the XML-based file format standards.</UL>
+At various times, the OpenOffice.org Foundation will specify new versions of these
+standards. In the case of the file formats and the APIs, it is the intent to publish and
+submit these standards to appropriate standards bodies such as OASIS, IETF, and/or
+the W3C. As previously specified, these standards will bear specific version
+specifications, allowing the compliance testing of implementations and products
+against these standards.
+
+<P ALIGN=right VALIGN=bottom><A HREF="contributions.html">back</A> </P>
+
+</body>
+</html>
+
diff --git a/content/white_papers/OOo_project/preface.html b/content/white_papers/OOo_project/preface.html
new file mode 100644
index 0000000..c0ed2f6
--- /dev/null
+++ b/content/white_papers/OOo_project/preface.html
@@ -0,0 +1,42 @@
+<html><head>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+<h2>The OpenOffice.org Project</h2>
+<br><br>
+<P><B>Preface</B>
+
+<p>
+The purpose of this paper is to provide a strategic overview of the OpenOffice.org
+project. It is designed to deliver an introduction to the details of the principles and
+mechanisms involved in the operation project. Having a good understanding of
+these principles and mechanisms is key for anyone interested in becoming involved
+in the OpenOffice.org project.</p>
+<p>It is expected that as the OpenOffice.org project matures, some of these details will
+evolve. This document will be updated periodically to reflect the nature of these
+changes to the strategies of the OpenOffice.org project.</p>
+<BR>
+<p><A NAME=history><B>History</B></A></p><BR>
+<TABLE WIDTH=100% BORDER=0>
+<TR>
+<TD><B>Version</B></TD>
+<TD> </TD>
+<TD><B>Publication Date</B></TD>
+<TD> </TD>
+<TD><B>Change Notes</B></TD>
+</TR>
+<TR>
+<TD>Version 1.0</TD>
+<TD> </TD>
+<TD>7/19/00</TD>
+<TD> </TD>
+<TD>First version of this paper. Released at the OpenOffice.org launch</TD>
+</TR>
+</TABLE>
+
+<P ALIGN=right VALIGN=bottom><A HREF="introduction.html">next</A> </P>
+
+
+</body>
+</html>
+
diff --git a/content/white_papers/OOo_project/strategy.html b/content/white_papers/OOo_project/strategy.html
new file mode 100644
index 0000000..b7ada19
--- /dev/null
+++ b/content/white_papers/OOo_project/strategy.html
@@ -0,0 +1,137 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<title>Licensing Strategy</title>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+</head>
+<body>
+<h2>Licensing Strategy</h2>
+
+<br>
+<p>
+OpenOffice.org uses a dual-license strategy for the source code of the projects
+technology. The two licenses are:
+</p>
+<ul>
+<li type=disc><a href="../../licenses/gpl_license.html">GNU General Public License (GPL)</a>
+<li type=disc><a href="../../licenses/sissl_license.html">Sun Industry Standard Source License (SISSL)</a></ul>
+<p>
+The dual-license mechanism enables the fullest degree of open and free access to the
+technology for both the GPL community as well as other developer communities
+that all wish to develop and deliver compatible, high-quality products for a
+networked world — powered with open office productivity services technology.
+</p>
+
+<br>
+<a name=dual_license><b>The Dual License Strategy</b></a>
+<br>
+<p>
+The key objectives for licensing the OpenOffice.org project source code are to enable
+it to:
+</p>
+<br>
+<p>
+1. Be compatible and accessible to projects using the GNU GPL. The diversity,
+innovation, and momentum of projects within the GPL community mandate that
+the OpenOffice.org technology use the GPL licensing.<br><br>
+2. Provide a licensing structure for other open communities that are incompatible
+with GNU GPL licensing. Again, the extensiveness of such projects and their
+diversity of application require OpenOffice.org to be accessible to these
+communities.
+</p>
+<br>
+<p>
+3. Be available for licensing to commercial companies wanting to utilize the
+technology within their products and/or provide branded versions of the
+technology as products to their customers. Many of these companies require more
+traditional commercial license terms and ancillary support services from another
+commercial vendor.
+</p>
+<br>
+<p>
+4. Support compliance with standards for the OpenOffice.org APIs and XML-based
+file formats. Keeping a cohesive adherence to these standards is recognized as key
+for the viability of such office productivity in a universal manner. Here, the use of
+a reference standard, open publishing of the reference specifications and any
+changes to such references, compliance testing mechanisms, and marks of
+compliance are the desirable tools required to achieve this goal for products and
+services.
+</p>
+<br>
+<p>
+Through dual licensing of OpenOffice.org technology, the first three points can be
+satisfied by choosing the companion license to the GPL. The second license must be
+able to specify requirements of compliance, while providing freedom of innovation
+by requiring that incompatible changes to the standard be openly published as
+source code. The second license also needs to provide adequate flexibility for
+enabling OpenOffice.org technology to be used within commercial products without
+compromise of the commercial vendors’ other licenses used in such products. The
+Sun Industry Standard Source License (SISSL) satisfies these requirements. The
+SISSL specification of a Standard (Exhibit B) to which compliance is required
+provides the clause to which licensees must retain compliance for their use of
+technology in distributed products. If a licensee makes incompatible modifications,
+the license specifies that a reference implementation of the modifications must be
+published back to Sun Microsystems under the original SISSL terms and conditions.
+</p>
+
+<br>
+<p>
+<a name=specifics><b>Specifics of the OpenOffice.org License Strategy</b></a>
+</p>
+
+<br>
+<p>
+<a name=dual_licensing_standards><b>Dual Licensing and Standards Compatibility</b></a><br>All source code of the OpenOffice.org project is dual licensed using the GNU GPL
+licenses<sup>1</sup> and the OpenOffice.org SISSL. Exhibit B of the OpenOffice.org SISSL will
+specify that the GNU GPL or LGPL source code, with the same version number, is
+the reference standard for that specific SISSL-licensed source code version.<br><br>
+This circular mechanism ensures that SISSL licensees are required to maintain
+compatibility with the GPL community versions of the same source code APIs and
+file formats. Sun Microsystems will publish any supplied modification reference
+implementations under the dual license (GPL/LGPL + SISSL) so that all
+communities have access to such modifications.<br><br>
+The SISSL License will be issued by Sun Microsystems, Inc., to SISSL licensees via a
+click-thru license hosted at the OpenOffice.org source code repository. This license is
+granted to the licensee for no fee or royalty charge.
+</p>
+<br>
+<p>
+<a name=specification><b>Specification of Standard Versions</b></a><br>The specification for each Standard Version as used by the licensing mechanism will
+be specified and published by the OpenOffice.org project under the governance of
+the OpenOffice.org Steering Committee.
+</p>
+
+<br>
+<p>
+<a name=staroffice><b>StarOffice Brand Usage</b></a>
+</p>
+
+<br>
+<p>
+In conjunction with the dual-license scheme, Sun Microsystems will provide a
+compatibility testing service to OpenOffice.org licensees for a fee. This service will
+be charged on a per-platform, per-version basis. Upon achieving compatibility
+certification for the specific product, the licensee will be authorized to use the
+StarOffice brand on the version of their product for that specifically tested platform
+version.
+</p>
+<br>
+<p>
+The provisions for use of the well-known StarOffice mark on a license's compatible
+products benefits them by delivering the market recognition already established by
+the mark and leveraging expanding market recognition of the mark developed by
+Sun Microsystems and other StarOffice mark vendors.<br><br>
+Additionally, the StarOffice mark conveys a signature of compatibility and
+confidence to users. This delivers a significant value to the vendor, their product,
+and the user.
+</p>
+
+<br>
+<p>
+1. <b>Note:</b> All libraries and embeddable components of the OpenOffice.org dual license will use the Lesser GPL (LGPL).
+</p>
+
+<p align=right valign=bottom><a href="introduction.html">back</a> <a href="contributions.html">next</a> </p>
+</body>
+</html>
+
diff --git a/content/white_papers/index.html b/content/white_papers/index.html
new file mode 100755
index 0000000..61c33fc
--- /dev/null
+++ b/content/white_papers/index.html
@@ -0,0 +1,30 @@
+<!DOCTYPE html>
+<html><head>
+<title>White Papers</title>
+<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8">
+</head>
+<body>
+
+<h2>White Papers</h2>
+<p><i>Last Updated 2002-10-31</i></p>
+<p><br>
+ The following white papers are available. Please check back periodically as
+ more information becomes available.
+<ul>
+ <li>"<a href="http://development.openoffice.org/releases/">OpenOffice.org Roadmap and Codeline Information</a></li>
+ <br>
+ <li>"The OpenOffice.org Project." Sun Microsystems<br>
+ <i>Foundations of Office Productivity in a Networked
+ Age</i><br>
+ Formats: <a href="OOo_project/OOo_project.html">HTML</a> | <a href="OOo_project/OOo_project.pdf">PDF</a> |
+ <a href="OOo_project/OOo_project.ps">Postscript</a>
+ </li><br>
+ <li>"OpenOffice.org Technical Overview." Sun Microsystems<br>
+ Formats: <a href="tech_overview/tech_overview.pdf">PDF</a>
+ | <a href="tech_overview/tech_overview.sdw">SDW</a> | <a href="tech_overview/tech_overview.html">HTML</a>
+ </li><br>
+</ul>
+<!-- comment -->
+</body>
+</html>
+
diff --git a/content/white_papers/tech_overview/tech_overview.html b/content/white_papers/tech_overview/tech_overview.html
new file mode 100644
index 0000000..61b4f56
--- /dev/null
+++ b/content/white_papers/tech_overview/tech_overview.html
@@ -0,0 +1,1661 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<title>The OpenOffice.org Source Project</title>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+</head>
+<body>
+
+
+<h2>The OpenOffice.org Source Project</h2><br><br>
+
+<b>Technical Overview</b>
+<p>
+<b>Sun Microsystems, Inc.</b><br>
+901 San Antonio Road<br>
+Palo Alto, CA 94303<br>
+1 (800) 786.7638<br>
+1.512.434.1511<br>
+<p>
+<b>Copyrights and Trademarks</b>
+<p>
+Copyright 2000 Sun Microsystems, Inc., 901 San Antonio Road, California 94303, U.S.A. All rights reserved.
+<p>
+This documentation is distributed under licenses restricting its use. You may make copies of and redistribute it, but you may not
+modify or make derivative works of this documentation without prior written authorization of Sun and its licensors, if any.
+<p>
+Sun, Sun Microsystems, the Sun logo, StarPortal, StarOffice,the StarOffice logo, Java, JavaBeans, JavaScript, and the Java
+Coffee Cup are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.
+<p>
+UNIX ® is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd.
+<p>
+DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND
+WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
+PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE
+HELD TO BE LEGALLY INVALID.
+<p>
+<font SIZE="5">Contents</font>
+<p>
+<a href="#1">Preface</a><br>
+ <a href="#2">History</a><br>
+<p>
+CHAPTER 1: <a href="#3">Summary</a><br>
+<p>
+CHAPTER 2: <a href="#4">OpenOffice.org Components</a><br>
+<p>
+ <a href="#5">OpenOffice.org Suite</a><br>
+ <a href="#6">OpenOffice.org wordprocessor application</a><br>
+ <a href="#7">OpenOffice.org spreadsheet application</a><br>
+ <a href="#8">OpenOffice.org presentation application</a><br>
+ <a href="#9">OpenOffice.org drawing application</a><br>
+ <a href="#10">OpenOffice.org data charting application</a><br>
+ <a href="#11">System Integration</a><br>
+<p>
+CHAPTER 3: <a href="#12">Interoperability</a><br>
+<p>
+ <a href="#13">File Formats</a><br>
+ <a href="#14">Component Technology</a><br>
+ <a href="#15">The OpenOffice.org Component Technology</a><br>
+<p>
+CHAPTER 4: <a href="#16">Openness</a><br>
+<p>
+ <a href="#17">XML File Format</a><br>
+ <a href="#18">Application Programming Interfaces</a><br>
+ <a href="#19">Application Areas</a><br>
+ <a href="#20">Design Principles</a><br>
+ <a href="#21">Architectural Paradigm</a><br>
+ <a href="#22">Object Model</a><br>
+ <a href="#23">Common Design Patterns</a><br>
+ <a href="#24">Module Categories</a><br>
+ <a href="#25">Summary</a><br>
+<p>
+CHAPTER 5: <a href="#26">Architecture</a><br>
+<p>
+ <a href="#27">Layered architecture</a><br>
+ <a href="#28">System abstraction layer</a><br>
+ <a href="#29">Operating system layer</a><br>
+ <a href="#30">Runtime library</a><br>
+ <a href="#31">Standard Template library</a><br>
+ <a href="#32">Visual Class library</a><br>
+ <a href="#33">Infrastructure layer</a><br>
+ <a href="#34">Virtual Operating System layer</a><br>
+ <a href="#35">Tools libraries</a><br>
+ <a href="#36">Universal Network Objects</a><br>
+ <a href="#37">Universal Content Broker</a><br>
+ <a href="#38">OpenOffice.org Compound Objects</a><br>
+ <a href="#39">OpenOffice.org Scripting and Basic library</a><br>
+ <a href="#40">Framework layer</a><br>
+ <a href="#41">OpenOffice.org Application framework library</a><br>
+ <a href="#42">SVX Library</a><br>
+ <a href="#43">Application layer</a><br>
+<p>
+CHAPTER 6: <a href="#44">Build Environment</a><br>
+<p>
+ <a href="#45">Open Source projects</a><br>
+ <a href="#46">The Build Experience</a><br>
+ <a href="#47">Build Requirements</a><br>
+ <a href="#48">Downloading the Source</a><br>
+ <a href="#49">Build Prerequisites</a><br>
+ <a href="#50">Build and Install Instructions</a><br>
+ <a href="#51">Build Tools & Makefiles</a><br>
+ <a href="#52">Build Environment</a><br>
+ <a href="#53">Build Troubleshooting</a><br>
+ <a href="#54">Porting to Other Systems</a><br>
+ <a href="#55">Build Documentation & Infrastructure</a><br>
+ <a href="#56">Outlook</a><br>
+ <a href="#57">Current Source Tree</a><br>
+<p>
+CHAPTER 7: <a href="#58">Future Steps</a><br>
+<p>
+ <a href="#59">An Open World Component Technology</a><br>
+ <a href="#60">Current Situation</a><br>
+ <a href="#61">A Short Term Solution</a><br>
+ <a href="#62">Vision</a><br>
+ <a href="#63">Unified Component Ware</a><br>
+ <a href="#64">Outlook</a><br>
+<p>
+CHAPTER 8: <a href="#65">Appendix A</a><br>
+<p>
+<a NAME="1"></a><font SIZE="5">Preface</font>
+<p>
+The purpose of this paper is to provide a technical overview of the OpenOffice.org source
+project.
+<p>
+It is expected that as the OpenOffice.org source project matures, some of these details will
+evolve. This document will be updated periodically to reflect the nature of these changes
+to the OpenOffice.org source project. If you would like to contribute to any updates to
+this document, please join the OpenOffice.org general mailing list (www.openoffice.org).
+<p>
+The names used in this document for OpenOffice components, such as "OpenOffice.org
+wordprocessor application" are placeholders. The OpenOffice.org community will
+ultimately decide what these final names will be. This document will be updated when
+the component names have been finalized.
+<p>
+<a NAME="2"></a><font SIZE="5">History</font>
+<p>
+<pre>
+<b>
+Version Publication Date Change Notes</b>
+
+Version 1.0 9/12/2000 First version of this paper.
+</pre>
+<p>
+<a NAME="3"></a><font SIZE="5">CHAPTER 1</font>
+<br>
+<font SIZE="5">Summary</font>
+<p>
+Through the OpenOffice.org source project, Sun Microsystems is open-sourcing the
+technology that powers its StarOffice[tm] office productivity application suite. Sun
+recognizes that the open source community expects openness, interoperability, and
+adherence to standards and, now that the underlying technology of the StarOffice suite
+will be available to the community in the form of the OpenOffice.org sources and
+binaries, Sun presents in this document the OpenOffice.org suite's technological
+foundations and where they stand with respect to these expectations.
+<p>
+The OpenOffice.org suite's high level of interoperability derives from the standards it
+supports as well as its premier import/export interfaces with the various office
+productivity applications produced by Microsoft. The OpenOffice.org suite employs a
+component-based development system that exemplifies all the important characteristics of
+Component Ware - consistent interface allocation, support for important component
+standards, transparent localization components, batch job capability, and platform
+independence.
+<p>
+OpenOffice.org's component technology is open, object oriented, interface based, and
+independent of both platform and development system. The OpenOffice.org API is
+version independent, scalable, durable, and re-applicable. Because the component
+technology is used in its implementation, the OpenOffice.org API is programming
+language independent.
+<p>
+XML replaces binary as OpenOffice.org's file format and becomes the suite's new native
+file format. Sun and OpenOffice.org are positioning XML, with its extremely high
+standards profile, as the next standard for exchange of office documents.
+<p>
+<a NAME="4"></a><font SIZE="5">CHAPTER 2</font>
+<br>
+<font SIZE="5">OpenOffice.org Components</font>
+<p>
+<a NAME="5"></a><font SIZE="5">OpenOffice.org Suite</font>
+<p>
+OpenOffice.org is a unified suite of productivity applications for all common office
+applications, including such functions as word processing, spreadsheets, drawings,
+presentations, data charting and formula editing. All components of the suite employ the
+same user interface concepts and underlying technology. They interoperate closely with
+one another, supporting features like inter-application copy-and paste and drag-and-drop
+for creating compound documents. It is straightforward to embed a spreadsheet in a text
+document, for example. They also interoperate well with other common desktop
+productivity application suites, including the various office productivity applications
+produced by Microsoft, for ease of document exchange. A scripting environment called
+OpenOffice.org Basic is supported in all OpenOffice.org components to automate work or
+build solutions.</p>
+<p>
+<a NAME="6"></a><font SIZE="4">OpenOffice.org wordprocessor application <sup>1</sup></font>
+<p>
+The OpenOffice.org wordprocessor application is a powerful tool for creating
+professional documents, reports, newsletters, and brochures. It is easy to integrate images
+and charts in documents, create business letters and extensive text documents with
+professional layouts, as well as create and publish Web content.</p>
+<p>
+Footnote:
+<p>
+1 Component names are placeholders and will be replaced with actual names when said names are
+finalized; see the Preface for more information.
+<p>
+<a NAME="7"></a><font SIZE="4">OpenOffice.org spreadsheet application</font>
+<p>
+The OpenOffice.org spreadsheet application features decision making analysis tools for
+performing advanced spreadsheet functions and data analysis. Charting tools generate
+presentation applicationive, high-quality 2D and 3D charts.
+<p>
+<a NAME="8"></a><font SIZE="4">OpenOffice.org presentation application</font>
+<p>
+The OpenOffice.org presentation application is a tool for creating multimedia
+presentations. Included are 2D and 3D clipart, special effects animation, and high-impact
+drawing tools.
+<p>
+<a NAME="9"></a><font SIZE="4">OpenOffice.org drawing application</font>
+<p>
+The OpenOffice.org drawing application is a vector-oriented drawing module that enables
+the creation of dynamic 3D illustrations and special effects.
+<p>
+<a NAME="10"></a><font SIZE="4">OpenOffice.org data charting application</font>
+<p>
+The OpenOffice.org data charting application presents complex data in visually
+presentation applicationive ways, from colorful 3D charts to simple pie, bar, and line
+diagrams.
+<p>
+<a NAME="11"></a><font SIZE="5">System Integration</font>
+<p>
+The overarching goal for the OpenOffice.org suite is to provide a comprehensive set of
+solutions for all office related functionality in an open world. The focus for all
+OpenOffice.org components is office functionality.
+<p>
+This is the reason why all office components should provide a perfect integration into
+already existing environments. Instead of competing with already accepted applications,
+the OpenOffice.org source project will provide the flexibility to use the office
+functionality in these applications as integrated parts. This will allow the use, for
+example, of office productivity files from a variety of vendors, including Microsoft, as
+mail attachments on every platform. In the future, it will also open up a way to build
+highly sophisticated applications and solutions with integrated office functionality.
+<p>
+Future releases of the OpenOffice.org applications should provide the flexibility to use
+different messaging components for Mail and News or let the user decide which tools he
+wants to use to explore the filesystem, while at the same time the office components can
+be an integrated part inside this application to deal with word-processing, spreadsheet,
+etc. related content.
+<p>
+Some technology used in the StarOffice product was licensed from other companies.
+Accordingly we are not able to provide the following technologies as Open Source under
+the OpenOffice.org source project:
+<ul>
+<li>Bristol XPrinter - printing on UNIX ® platforms
+<li>L&H International CorrectSpell, Intl. Electronic Thesaurus - spell checking,
+international dictionaries & thesaurus
+<li>Inso Word for Word - document filters for document formats other than MS Office
+<li>Adabas D - database engine</li>
+</ul>
+<p>
+Future releases of the OpenOffice.org components may provide open source replacement
+for these parts, which will provide similar functionality.
+<p>
+<a NAME="12"></a><font SIZE="5">CHAPTER 3</font>
+<br>
+<font SIZE="5">Interoperability</font>
+<p>
+For exchanging information it is important that two individuals have a common language.
+For exchange electronic information today it is not hard to transport this information to
+different system, instead the problem is in most cases that users use different applications
+to do their work and to create content. So very often in the domain of office productivity
+you can only read the document with the same application you created the content,
+because the file format are proprietary. In some case it is also required to use the same
+release of the application, the same operation system release or run this on the same
+platform.
+<p>
+To give the user the freedom to use applications and the system which is appropriate for his
+work, it is important that the system is able to handle a widespread set of file formats.
+Especially for word-processing, spreadsheet, presentation it is often necessary to be able
+to read the different binary formats used by the various office productivity applications
+produced by Microsoft.
+<p>
+On the other hand interoperability is not only necessary for content. It is also necessary
+that the components which are able to process the different file formats can be used in an
+heterogeneous environment to build up solutions. Otherwise you would be locked into
+another application space. Today's software technology is moving forward from having
+libraries to component technology, which will not only allow using different programming
+languages to build solutions, instead it will in most cases support using a scripting
+language to provide the logical glue between high-level component build rapidly easy
+adaptable software solutions.
+<p>
+<a NAME="13"></a><font SIZE="5">File Formats</font>
+<p>
+One of our primary objectives is to provide interoperability with existing solutions in the
+same application domain. We support a wide range of standard file formats such as
+HTML, RTF, GIF, and JPEG as well as Microsoft's proprietary file formats because of
+their widespread use. OpenOffice.org provides the highest quality document import and
+export functionality for the various office productivity applications produced by
+Microsoft.
+<p>
+<pre>
+<b>Documents formats</b>
+ASCII CSV Microsoft Excel for Windows 97/2000
+ASCII Text Microsoft Word for Windows 6.0
+dBase Microsoft Word for Windows 95
+DIF Microsoft Word for Windows 97/2000
+Encoded Text PowerPoint 97/2000
+HTML Rich Text Format (RTF)
+Lotus 1-2-3 1.0 DOS SYLK
+Lotus 1-2-3 1.0 Windows Text DOS
+Lotus Freelance Text OS/2
+Microsoft Excel for Windows 5.0 Text Unix
+Microsoft Excel for Windows 95 Text Win
+
+<b>Graphic formats</b>
+Adobe Photoshop (psd) Portable Network Graphics (png)
+AutoCAD (dxf) PPM
+CompuServe Graphics (gif) SGF
+Computer Graphics Metafile (cgm) SGV
+Encapsulated PostScript (eps) SUN Raster-Format
+JPEG Bitmaps (jpg) TGA
+Kodak Photo-CD (pcd) TIFF-Bitmap
+Macintosh PICT (pct) Truevision TARGA (tga)
+MS Windows Metafile (EMF) Windows Bitmap (Bmp)
+OS/2 Metafile (met) Windows Metafile (wmf)
+Paint Brush (pcx) XBM
+PBM XPM
+PGM
+</pre>
+<p>
+<a NAME="14"></a><font SIZE="5">Component Technology</font>
+<p>
+Despite the rise of the graphical user interface and a constant flow of new innovations in
+the software industry, software development has become only more complicated over the
+years. Creating high quality applications increases demands on the user, which in turn
+lead to more and more expendable programs. Component based program development
+systems promise a welcome change in this trend. They are based on the JavaBeans
+architecture or the Component Object Model (COM), which are also called Component
+Ware. The programmer can access previously prepared components (building blocks)
+with these products, and use them in applications. The components are ready for
+immediate use once they have been adapted to the operational area.</p>
+<p>
+The authors of the StarOffice product experienced this situation three years ago when
+developing a new software architecture, which for the first time made an office suite
+available on different platforms for use as an important building block. In the subsequent
+planning and development period, a need for the following attributes in this new
+architecture was realized:
+<ul>
+<li><font SIZE="4">Consistent Interface Allocation</font><br>
+An important aspect in Component Ware development is the way the overall
+application is dissected into individual units. The programmer must be offered exactly
+the needed number of single components. The more complex the application, the more
+difficult it is to distribute these components reasonably. The simpler and more logical
+the application, the higher its acceptability.
+<li><font SIZE="4">Support for Various Component Standards</font><br>
+While the COM standard in Windows software is the most widely known component
+standard, the JavaBeans components and CORBA interfaces are among the most
+common in the professional business field and are accepted as standards in the open
+world. Since there is not yet a general established industry standard in this area for all
+platforms, the component model has to provide bridges between these different
+technologies.
+<li><font SIZE="4">Localization-Transparent Components</font><br>
+Current Component Ware extensions should take advantage of the network for
+component communication. Pure client components are inapplicable for modern
+network use. Modern Component Ware must allow for delegation of a portion of an
+application to a central server. On the other hand, components running locally on a
+desktop system should not lose performance because of network communication
+protocols when all components are running on one machine.
+<li><font SIZE="4">Batch Job Ability</font><br>
+Previous Component Ware products employed a visual and user fixed basic approach
+for batch operations. User queries with hard coded components can bring the complete
+server operation to a halt. For batch operations within the server it should be possible
+to process content without requiring a visual representation.
+<li><font SIZE="4">Platform Independence</font><br>
+Especially in these times of
+ network computers and operating system upheaval, it is important that modern
+ Component Ware be able to select a platform independent extension. The
+ interface should be defined in a platform independent way so that program code
+ can be easily ported.</li>
+
+
+
+
+</ul>
+<a NAME="15"></a><font SIZE="5">The OpenOffice.org Component Technology</font>
+<p>
+The OpenOffice.org suite provides a component technology named Universal Network
+Objects, which adheres to all these requirements of modern Component Ware and it is
+formed on the Object Technology level, which is the basis upon which the OpenOffice.org
+API is set up.
+<p>
+This component technology is:
+<ul>
+<li><font SIZE="4">Open</font><br>
+It supports all the popular component standard communication protocols such as
+CORBA, JavaBeans, OLE Automation (Windows Scripting Host, Visual Basic,
+Delphi, and so forth), JavaScript, Phyton, Perl, etc. scripting languages, as well as
+native integration in the C++ and C programming languages.
+<li><font SIZE="4">Object Oriented</font><br>
+It is object oriented and therefore supports concepts such as aggregation, inheritance,
+exception handling and polymorphism.
+<li><font SIZE="4">Interface Based</font><br>
+Its functions are integrated into various interfaces. Function areas of similar structures
+have access to the same interfaces, so that the programmer can easily feel at home in
+the component world.
+<li><font SIZE="4">Platform Independent</font><br>
+It is specified to be platform independent and is available on all platforms that run
+OpenOffice.org.
+<li><font SIZE="4">Exception Able</font><br>
+It offers exception ability, which means that it can allow itself to be mapped onto the
+inserted development system mechanism - for example onto C++ Exceptions and Java
+Exceptions.
+<li><font SIZE="4">Development System Independent</font><br>
+It can be used with all current development environments and programming
+languages, including C++, C, Visual Basic, Windows Scripting Host and all systems
+which support COM, CORBA, JavaBeans components, and OLE Automation.
+<li><font SIZE="4">Network Able</font><br>
+Components based on the component
+ technology can communicate on a network and can also delegate functions on a
+ remote server, for example, to offer access to the complete text processing
+ functions on Internet appliances.</li>
+
+
+
+</ul>
+<p>
+<a NAME="16"></a><font SIZE="5">CHAPTER 4</font>
+<br>
+<font SIZE="5">Openness</font>
+<p>
+Opening up all specification, file formats, technologies and last but not least the source
+code, will help ensure that no one can be locked into an application, platform or
+environment space. But just providing all this information to everyone is not enough.
+Openness will also required that already existing open standards and technologies were
+used when ever appropriate and also the project over time will evolve newer technologies
+and adapt other open standards.</p>
+<p>
+<a NAME="17"></a><font SIZE="5">XML File Format</font>
+<p>
+We adopted XML to replace the old binary file format and become the OpenOffice.org
+suite's new native file format. Our goals were twofold: to have a complete specification
+encompassing all components, and to provide an open standard for office documents. One
+single XML format applies to different types of documents - e.g., the same definition
+applies for tables in texts and in spreadsheets. XML is ideal as an open standard because
+of the free availability of XML specifications and DTDs, and XML's support for XSL,
+XSLT, Xlink, SVG, MathML, and many other important and emerging standards.
+<p>
+Beside replacing the binary file format with XML, the OpenOffice.org suite will use XML
+internally for exchanging any type of content between the different applications.
+OpenOffice.org provides today an infrastructure for using different XML components.
+The XML-Parser and the XML-Printer are all implemented as components. Every of
+these component support the Simple API for XML (SAX). This infrastructure will allow
+in the future to dynamically configure a pipelines of different XML components, like
+XML-Parser, XSLT-Processor, etc. to process XML-Input and Output. This will allow
+transformation of XML-Data into different formats on the fly, without storing
+intermediate files and parse them again for every transformation step.
+<p>
+<a NAME="18"></a><font SIZE="5">Application Programming Interfaces</font>
+<p>
+The OpenOffice.org API is based on the OpenOffice.org component technology and
+consists of a wide range of interfaces defined in a CORBA-like IDL.
+While the component technology determines how the components or applications
+communicate with each other, the OpenOffice.org API defines the interface for accessing
+office functionality from different programming languages. This interface structure is very
+important in determining the degree to which re-application of a development is possible.
+<p>
+The interfaces defined by the OpenOffice.org API are characterized as follows:
+<ul>
+<li>They are completely defined component <b>interfaces</b> with the environment.
+<li>They are <b>version independent</b> and <b>scalable</b>.
+<li>They are <b>durable</b>.
+<li>They are <b>re-applicable</b>.</li>
+</ul>
+Unlike other office suite APIs, the OpenOffice.org API does not simply reflect the
+features of preexisting implementations. Rather, it has been designed from the viewpoint
+of application and component developers. It offers programming interfaces for nearly all
+OpenOffice.org components and makes it possible to integrate new components.
+<p>
+<a NAME="19"></a><font SIZE="4">Application Areas</font>
+<p>
+There are multiple ways to use OpenOffice.org APIs. First, there is the typical macro
+programming for running certain tasks automatically. Secondly, parts of OpenOffice.org
+can be run as components of other programs; e.g., OpenOffice.org components are
+accessible as JavaBeans components.
+<p>
+A more advanced application is to modify OpenOffice.org components by wrapping them
+into replacement components or integrating completely new components with
+OpenOffice.org.
+<p>
+A very interesting application area is to replace the user interface of OpenOffice.org and
+build a completely different application domain.
+<p>
+<a NAME="20"></a><font SIZE="4">Design Principles</font>
+<p>
+Some principles that are important in all our designs are:
+<ul>
+<li><font SIZE="4">orthogonality</font><br>
+The API consists of interfaces which can easily be combined to serve special needs of
+certain objects.
+<li><font SIZE="4">scalability</font><br>
+We distinguish between functionality that is commonly needed and that which is
+required by specialized versions. Developers can always start with a minimum set of
+interfaces and add more step by step to embody more features.
+<li><font SIZE="4">reusability</font><br>
+We avoid creating specialized interfaces when a generic version is possible.
+<li><font SIZE="4">Remote usability</font><br>
+Services can be used efficiently from different processes or even different machines.
+<li><font SIZE="4">multithread enabled</font><br>
+Services can be used from multiple
+ threads.</li>
+
+</ul>
+<a NAME="21"></a><font SIZE="4">Architectural Paradigm</font>
+<p>
+Our architectural decision is Interfaces and Support-Classes instead of Implementation
+Inheritance.
+<p>
+Interfaces and Support-Classes means that objects communicate only by interfaces.
+Support classes are used for recurring implementations. This was the choice for our
+design because components are highly independent of environment, language and version
+Implementation Inheritance means partly implemented base classes from which
+specialized classes derive interface and implementation. This paradigm was not our
+choice, because in larger systems this leads to fat interfaces or deep inheritance hierarchy.
+In addition, components depend on the environment, mostly via their base class, and are
+programming language dependent and highly version dependent.
+<p>
+<a NAME="22"></a><font SIZE="4">Object Model</font>
+<p>
+The OpenOffice.org API is designed for and implemented using the OpenOffice.org
+Component Technology. Therefore the OpenOffice.org API is programming language
+independent and can be used from C/C++, Java, and several scripting languages. For
+other languages, only a language binding needs to be provided to access the whole
+OpenOffice.org API. The API is made up by following stereotypes:
+<ul>
+<li><font SIZE="4">implementation classes</font><br>
+These are not actually part of the API, but are mentioned here for better
+understanding. Implementation classes are implementations of services using a real
+programming language. Normally developers who use services do not have to deal
+with the implementation itself on the API level. Objects are usually not translated into
+language concepts for an application that uses them, but rather for the implementer of
+the class. A good example is an implementation class similar to a concrete Java-class.
+<li><font SIZE="4">services</font><br>
+Specifications of objects are called services. One can think of a service as a contract
+which is beneficial to both sides: the implementation class that supports certain
+services and the application that uses this component for those services. Services
+usually describe the interfaces which they implement and a set of their properties.
+Although services are normally not translated into language concepts, a service may
+be considered to be similar to an abstract Java class.
+<li><font SIZE="4">interfaces</font><br>
+Specifications of a single aspect on an API level are called interfaces. A service can be
+considered to be a legally proven text module for contracts. Services can be combined
+to create contracts. Interfaces are very much like Java technology interfaces.
+<li><font SIZE="4">structs</font><br>
+Plain data blocks are specified as structs . Structs, therefore, do not have methods. The
+advantage of structs is that they can transferred as they are to a different process or
+even a different machine, which increases efficiency of interprocess and remote calls.
+With Java technology, structs are represented as a class which consist only of data
+members and get and set methods.
+<li><font SIZE="4">exceptions</font><br>
+Exceptions are extraordinary results from method calls. Exceptions are used for error
+handling just as in the Java technology.
+<li><font SIZE="4">constants/constant groups/enums</font><br>
+Constant values are split into two
+ categories: constants - which can be grouped and can have numeric or character
+ string values, and enums - which contain a fixed set of numeric values. In the
+ Java technology, both are represented as classes with constant data members.</li>
+
+
+
+
+</ul>
+<p>
+<a NAME="23"></a><font SIZE="4">Common Design Patterns</font>
+<p>
+The OpenOffice.org API uses heavily designed patterns, which provide a very consistent
+overall design. Some examples of application domain unspecific design patterns are:
+<ul>
+<li><font SIZE="4">Factory environment/container</font><br>
+New instances of services are created using factories. Factories of contents can
+emanate from the container object or from the environment. For efficiency, factories
+for iterators of all kinds, including cursors, are provided by the container.
+<li><font SIZE="4">Property Sets/-Access etc.</font><br>
+A set of interfaces makes the properties specified in the services accessible. Properties
+can be viewed as non-structural data members of objects, such as color or font. The
+variety of access interfaces covers the spectrum from convenient local access to fast
+remote access.
+<li><font SIZE="4">Collections/Containers</font><br>
+A collection in our terminology gives access to a set of similar sub-objects. A
+container allows replacement, insertion and removal of these sub-objects. A wide
+variety of predefined interfaces is available for this design pattern.
+<li><font SIZE="4">Enumerators/Iterators/Cursors</font><br>
+Enumerators, iterators and cursors are used for efficiently listing contained objects.
+Cursors in text play an especially major role, because indexing of text is not
+reasonable.
+<li><font SIZE="4">X...Supplier</font><br>
+To access structural but optional data members, we frequently offer supplier interfaces
+which in many cases only have one get method.
+<li><font SIZE="4">Events</font><br>
+Where it is of interest to get notification about certain status changes, there are
+services that offer methods to register and unregister listener interfaces. When the
+event occurs, a method at the listener interface is called and the event is given as an
+argument. This is the same as in the event concept in JavaBeans.
+<li><font SIZE="4">Exceptions for Error Handling</font><br>
+Exceptions constitute our
+ principal error handling concept. For asynchronous calls, exceptions are
+ transferred in callback events.</li>
+
+
+</ul>
+<a NAME="24"></a><font SIZE="4">Module Categories</font>
+<p>
+The OpenOffice.org API is organized in a hierarchical module concept which follows
+Java technology package or CORBA conventions.
+<ul>
+<li><font SIZE="4">office specific interfaces</font><br>
+e.g. For text documents, spreadsheet documents, drawing and presentation documents
+<li><font SIZE="4">integration framework</font><br>
+These interfaces make it possible to integrate new components into OpenOffice.org,
+e.g.: configuration management , Universal Content Broker
+<li><font SIZE="4">application domain independent</font><br>
+This very important category contains interfaces for property access, collections and
+contains, or streaming operations, as well as for attaching scripting engines and many
+more interfaces.
+<li><font SIZE="4">component system</font><br>
+The base of the suite is the handful of
+ interfaces which are necessary to deal with object model topics such as
+ lifetime control, querying interfaces, building bridges and instantiating
+ remote objects.</li>
+
+
+
+</ul>
+<a NAME="25"></a><font SIZE="4">Summary</font>
+<p>
+The results and benefits of the OpenOffice.org source projects principles and activities to
+date are manyfold. One can build new applications from components without modifying
+source code. One can use a familiar programming language. The entire API is
+documented in a reference manual ¯ http://soldc.sun.com/staroffice. A
+first release of a Development Kit, containing support of the OpenOffice.org Basic and
+also Java technology, is available.
+<p>
+<a NAME="26"></a><font SIZE="5">CHAPTER 5</font>
+<br>
+<font SIZE="5">Architecture</font>
+<p>
+The OpenOffice.org source project is based on an architecture that can provide
+comprehensive personal productivity to different UNIX-based systems and may be ported
+many other platforms as well. This is because the whole technology is based on a
+platform-independent approach. Less than 10% of the code is platform dependent. This
+acts as an abstraction layer for the upper software components. Because of the availability
+of C++-Compilers on every major platform, C++ is used as an implementation language.
+This allows to port the OpenOffice.org technology to a wide range of different platforms.
+The decision for an object oriented language gives the OpenOffice.org source project the
+opportunity deliver a fully object oriented architecture.
+<p>
+The following information will give just a rough overview over the overall architecture.
+Some components of the OpenOffice.org source project like the help-system or the setup
+application are not covered here. Many parts of the OpenOffice.org source project
+consists of more than one CVS module. In many cases one block in the architecture is
+covered by more than five CVS modules in the source tree.
+<p>
+<a NAME="27"></a><font SIZE="5">Layered architecture</font>
+<p>
+The whole architecture is based on a layered approach. There are four defined layers
+where each covers a special area of the functionality.
+<ul>
+<li><font SIZE="4">System Abstraction Layer</font><br>
+This layer encapsulates all system specific APIs and provide a consistent object
+oriented API to access system resources in a platform independent manner.
+<li><font SIZE="4">Infrastructure Layer</font><br>
+A platform independent environment for building application, components and services
+is provided by this layer. It covers many aspects of an object oriented API for a
+complete object oriented platform including a component model, scripting, compound
+documents, etc.
+<li><font SIZE="4">Framework Layer</font><br>
+To allow the reuse of implementations in different applications the layer provides the
+framework or environment for each application and all shared functionality like
+common dialogs, file access or the configuration management
+<li><font SIZE="4">Application Layer</font><br>
+All OpenOffice.org applications are part
+ of this layer. The way these applications interact is based on the lower
+ layers The chart shown below was created to depict the architecture of the
+ StarOffice suite but it is the same for the OpenOffice.org suite:</li>
+
+
+
+</ul>
+<p>
+<img alt="" border=0 height=330 src="staroffice_layers.gif" width=485>
+<p>
+<a NAME="28"></a><font SIZE="4">System abstraction layer</font>
+<p>
+The layered approach of the system architecture is one of the important facts to allow the
+easy porting of the technology to wide range of different system platforms. For this the
+architecture defines a virtual layer witch is called the System Abstraction Layer (SAL).
+All platform depended implementation take place below this layer or are part of some
+optional modules. In an ideal world an implementation of the SAL specific functionality
+and recompiling the upper layer module will allow you to run the applications. To provide
+the whole set of functionality the optional platform specific modules, like telephony
+support or speech recognition, have to be ported, too. To reduce the porting effort the set
+of functionality provide by the SAL is reduced to a minima set available on every
+platform. Also for some system the layer includes some implementations to emulate some
+functionality or behavior. For example on systems where no native multi threading is
+supported, the layer can support so called “user land” threads.
+<p>
+At this time the implementation of the platform dependent and independent parts of the
+graphical library is linked into one dynamically loaded shared library. So there is no well
+defined set of libraries which build up the SAL.
+<p>
+<a NAME="29"></a><font SIZE="4">Operating system layer</font>
+<p>
+The operating system layer (OSL) encapsulates all the operating system specific
+functionality for using and accessing system specific resources like files, memory,
+sockets, pipes, etc. The OSL is a very thin layer with an object oriented API. In contrast to
+the upper layer this object oriented API is a C-API. This will allow to easily port this
+layer to different platforms using different implementation languages. For embedded
+systems or internet appliances for examples an assembler language can be used to realize
+the implementation.
+<p>
+<a NAME="30"></a><font SIZE="4">Runtime library</font>
+<p>
+The runtime library provides all semi platform independent functionality. There is an
+implementation for string classes provided. Routines for conversion of strings to different
+character sets are implemented. The memory management functionality resides in this
+module.
+<p>
+<a NAME="31"></a><font SIZE="4">Standard Template library</font>
+<p>
+As a generic container library the standard template library is used. It supplies
+implementations for list, queues, stacks, maps, etc.
+<p>
+<a NAME="32"></a><font SIZE="4">Visual Class library</font>
+<p>
+The visual class library is one of the core libraries of the OpenOffice.org technology. The
+VCL encapsulate all access to the different underlying GUI systems. The implementation
+is separated into two major parts. One is completely platform independent and includes an
+object oriented 2D graphics API with metafiles, fonts, raster operations and the whole
+widget set use by the OpenOffice.org suite. This approach virtually guarantees that all
+widgets have the same behavior independently of the used GUI system on the different
+platforms. Also the look & feel and the functionality of the widgets are on all platforms the
+same.
+<p>
+Because of this design VCL doesn't encapsulate the native widgets or controls of the
+underlying GUI system. The platform dependent part implements a 2D-graphic drawing
+canvas which is used by the platform independent parts. This canvas redirect every
+functionality directly to the underlying GUI system. Currently there exists implementation
+for the Win32, X-Windows, OS/2 and Mac. The access to the printing functionality,
+clipboard and Drag & Drop is also realized inside the VCL.
+<p>
+<a NAME="33"></a><font SIZE="5">Infrastructure layer</font>
+<p>
+<a NAME="34"></a><font SIZE="4">Virtual Operating System layer</font>
+<p>
+To make the usage of system resources like files, threads, sockets,etc. more convenient
+the virtual operating system layer encapsulates all the functionality of the operating system layer
+into C++ classes. The C++ classes here offer an easy to use access to all system resources
+in an object oriented way.
+<p>
+<a NAME="35"></a><font SIZE="4">Tools libraries</font>
+<p>
+There are different small libraries building up a set of tool functionality. This includes a
+common implementation for handling date and time related data. There is in
+implementation for structured storages available. Other implementation provide a generic
+registry, typesafe management and persistence of property data.
+<p>
+<a NAME="36"></a><font SIZE="4">Universal Network Objects</font>
+<p>
+The so called Universal Network Objects are the component technology used inside the
+OpenOffice.org products. The component technology does not depend on any graphical
+subsystem, but is heavily based on multithreading and network communication
+capabilities.
+<p>
+The system consists of several pieces. An IDL-Compiler, which generates out of the
+specified definition of an interface a binary representation and the associated C-Header or
+Java technology files. The binary representation is platform and language independent
+and is at runtime used to marshall argument for remote function calls or to generate code
+on the fly for a specific language to access the implementation provided by the interface.
+This technique reduced the amount of generated code for the different language binding
+tremendously. The drawback is that not only for every language binding a specific
+backend for the code generation is needed, it is that for every specific compiler a bridging
+module is needed at runtime.
+<p>
+Many parts of the UNO technology are implemented as UNO components. This helps to
+create a very flexible system and also the extension of the system at runtime. For example
+by providing new bridges or communication protocols. UNO provides transparent access
+to components over the network or locally. For the communication over the network IIOP
+can be used. If the component are realized as shared libraries the component can be
+loaded by UNO into to the process memory of the application and every access of the
+component is just like a function call without any marshalling of arguments which is
+required for remote function call.
+<p>
+<a NAME="37"></a><font SIZE="4">Universal Content Broker</font>
+<p>
+The Universal Content Broker allows all upper layers to access different kind of structure
+content transparently. The UCB consists of a core and several Universal Content
+Providers which are used to integrate different access protocols. The current
+implementations provides content providers for the HTTP protocol, FTP protocol,
+WebDAV protocol and access to the local file system.
+<p>
+The UCB does not only provide access to the content, it also provides the associated meta
+information to the content. Actually there is synchronous and asynchronous mode for
+operations supported.
+<p>
+<a NAME="38"></a><font SIZE="4">OpenOffice.org Compound Objects</font>
+<p>
+The Compound Object implementation provide the functionality to build compound
+documents, where for example a spreadsheet is being embedded in a word-processor
+document.
+<p>
+The current implementation provides a platform independent implementation of all this
+functionality for compound documents and for embedding of visual controls like multi
+media players or different kind of viewers. All content of compound document is stored in
+a structured storage. The current implementation is compatible to the OLE structure
+storage format. This allows access to OLE compound documents on every platform where
+OpenOffice.org is available. On the Windows platform the implementation interact with
+the OLE services and will so allow a tight integration of all OLE capable applications.
+<p>
+<a NAME="39"></a><font SIZE="4">OpenOffice.org Scripting and Basic library</font>
+<p>
+The scripting functionality coming with the OpenOffice.org suite is a BASIC dialect
+featuring an interpreter that parses the source statements and generates meta instructions.
+These instructions can be executed directly by the supplied meta instructions processor or
+can be made persistent in modules or libraries for later access. All functionality supplied
+by the upper level application components is accessible via a scripting interface in the
+component technology. This will help to ensure that new components using the
+OpenOffice.org component technology can be fully scriptable without spending a huge
+amount of effort.
+<p>
+The scripting interfaces are also implemented as components which will allow an easy
+integration of other scripting languages. The interfaces provide functionality like core
+reflection and introspection similar to the functionality by the Java platform.
+<p>
+<a NAME="40"></a><font SIZE="5">Framework layer</font>
+<p>
+<a NAME="41"></a><font SIZE="4">OpenOffice.org Application framework library</font>
+<p>
+The Application framework library provides an environment for all applications. All
+functionality shared by all application and not provided by any other layer is realized
+here. For the framework every visual application has to provide a shell and can provide
+several views. The library provides all basic functionality so only the application specific
+features have to be added.
+<p>
+The Framework is also responsible for content detection and aggregation. The template
+management is provided here and the configuration management too. The Framework is
+in some areas related to the compound documents, because of the functionality for
+merging or switching menu- and toolbars. Also the capability for customization of all
+applications is provided by the library.
+<p>
+<a NAME="42"></a><font SIZE="4">SVX Library</font>
+<p>
+The SVX library provides shared functionality for all applications which is not related to
+a framework. So part of the library is a complete object oriented drawing layer which is
+used by several applications for graphic editing and output. Also a complete 3D-rendering
+systems is part of the drawing functionality.
+<p>
+The common dialogs for font selection, color chooser, etc. are all part of this library. Also
+the whole database connectivity is realized here.
+<p>
+<a NAME="43"></a><font SIZE="5">Application layer</font>
+<p>
+All applications like the wordprocessor application, spreadsheet application, presentation
+application, charting application, etc. build up this layer. All these applications are realized
+as shared libraries, which are loaded by the application framework at runtime. The
+framework provides the environment for all these applications and also provides the
+functionality for how these applications can interact.
+<p>
+<a NAME="44"></a><font SIZE="5">CHAPTER 6</font>
+<br>
+<font SIZE="5">Build Environment</font>
+<p>
+The following information provides an overview of the proposed Build Experience for
+OpenOffice.org and how we hope it will evolve. This information is intended for
+developers and engineering managers.
+<p>
+<a NAME="45"></a><font SIZE="5">Open Source projects</font>
+<p>
+Open Source projects follow by now a very familiar pattern when it comes to providing a
+Build Experience. This translates as follows:
+<ol>
+<li>cvs checkout OpenOffice
+<li>./configure
+<li>make
+<li>make install</li>
+</ol>
+The build tools are well known to the Open Source community - i.e., gmake, autconf, etc.
+This is the Build Experience that we want OpenOffice.org source project developers to
+work within. Not only should this be the sum total of the commands involved, but more
+importantly milestone builds should build cleanly on all supported platforms.
+The OpenOffice.org technology in its first release under the OpenOffice.org source
+project will not support the mode described above. The mode initially supported will not
+be far from this model, and it will contain the foundation for evolving to this model. The
+only implication is that build tools may not be the ones most familiar to the open source
+community. Sun is committed to providing a product that builds. This document will
+describe this Build Experience.
+<p>
+It is important to understand that the Build Experience will be an evolving model, one
+that will grow and gain from the experience of the Open Source Developer Community.
+<p>
+The task facing us is a challenging one. The OpenOffice.org suite is a very large
+application from any standpoint. It is a complex application consisting mainly of C++
+code employing templates and exception handling and supporting independent language
+binding for a distributed component based architecture.
+<p>
+<a NAME="46"></a><font SIZE="5">The Build Experience</font>
+<p>
+The Build Experience will cover the following areas:
+<ul>
+<li>Build Requirements
+<li>Downloading the Source
+<li>Build Prerequisites
+<li>Build and Install Instructions
+<li>Build Tools & Makefiles
+<li>Build Environment
+<li>Build Troubleshooting
+<li>Porting to New Platforms
+<li>Build Documentation and Infrastructure</li>
+</ul>
+<p>
+<a NAME="47"></a><font SIZE="4">Build Requirements</font>
+<p>
+The OpenOffice.org sources will build on the Solaris(TM) operating environment, Linux,
+and WIN32 platform. Work is in progress on the Macintosh platform. Each system will
+describe the software and hardware requirements to build on their respective systems.
+Typical of these will the version of gcc, the Java Technology JDK , hard disk and RAM
+sizes.
+<p>
+It is crucial that these requirements be understood at the outset. Building the
+OpenOffice.org sources is not a task to be taken lightly. It may turn out to be the largest
+open source project ever in terms of source size and time to build. The source and build
+environment size is in the region of 500MB and consists of approximately 40,000 files. It
+can take up to 18 hours to fully build from scratch, but this is rarely needed. The build
+environment is prepared to allow working with milestone builds.
+<p>
+<a NAME="48"></a><font SIZE="4">Downloading the Source</font>
+<p>
+The source may be downloaded using CVS, or ftp can be employed to download gzipped
+tarballs of the source. In addition, milestone completed builds will be made available in
+gzipped tarball format plus daily snapshots of the source.
+<p>
+<a NAME="49"></a><font SIZE="4">Build Prerequisites</font>
+<p>
+The OpenOffice.org technology relies on a number of external sources to be built.
+Instructions on where to locate and download these will be available.
+<p>
+<a NAME="50"></a><font SIZE="4">Build and Install Instructions</font>
+<p>
+The OpenOffice.org technology will use autoconf to check the integrity of the build
+environment and to set up the correct build environment on the supported platforms.
+<p>
+After setting up the build environment, the build and install instructions will support the
+make and make install concepts. Details on building all the source as well as build
+components will be available.
+<p>
+<a NAME="51"></a><font SIZE="4">Build Tools & Makefiles</font>
+<p>
+The OpenOffice.org technology is built using dmake from the http://dmake.wticorp.com .
+This is itself an open sourced project. The syntax is a make like syntax. The dmake
+options will support a dmake all, dmake <component> and dmake install concepts.
+<p>
+The OpenOffice.org source project team has also developed a number of development
+tools including support for Interface Definition Language formats, resource pre-processors
+and bitmap creators. All these will be fully explained.
+<p>
+<a NAME="52"></a><font SIZE="4">Build Environment</font>
+<p>
+The OpenOffice.org technology relies on a large set of environment variables as well as
+compiler pre-processor options and flags. These will be documented to support greater
+understanding of the build environment among developers.
+<p>
+The OpenOffice.org technology is a CVS module based source tree. These CVS modules
+will have an overview explanation plus an explanation of the order in which they are built.
+<p>
+<a NAME="53"></a><font SIZE="4">Build Troubleshooting</font>
+<p>
+A troubleshooting guide and Build FAQ will be published to support developers.
+<p>
+<a NAME="54"></a><font SIZE="4">Porting to Other Systems</font>
+<p>
+The OpenOffice.org technology for its supported platforms will rely on a bootstrap
+process that is in place in order to build it. To port the OpenOffice.org technology,
+developers will need to know how to create this bootstrap in the first place.
+<p>
+<a NAME="55"></a><font SIZE="4">Build Documentation & Infrastructure</font>
+<p>
+An online Build manual will exist to cover all the topics described above. There will also
+be a support infrastructure in place to deal with specific build issues. Bugzilla will be
+employed to store all bugs and issues arising from the build.
+<p>
+<a NAME="56"></a><font SIZE="5">Outlook</font>
+<p>
+Providing a clean Build Experience which is familiar and consistent to the Open Source
+Community is not only our aim but we see it as critical to the success of this project.
+Although this experience has not yet reached full fruition, Sun has determined not to
+delay the release of the source for this reason. It is more important that we engage with
+the community than to wait until we have replicated the same build experience. To this
+end we are committed to providing as clean a build as possible now while putting an
+infrastructure in place to allow us to evolve to a more standard model.
+<p>
+<a NAME="57"></a><font SIZE="5">Current Source Tree</font>
+<p>
+The OpenOffice.org source project will be among the largest open source projects. There
+are about 70 CVS modules with more than 35,000 files providing about 5,000,000 lines
+of code.
+<p>
+Appendix A gives a first overview over all CVS modules with a short description of the
+purpose. Additional information will be made available at the website
+/ .
+<p>
+<a NAME="58"></a><font SIZE="5">CHAPTER 7</font>
+<br>
+<font SIZE="5">Future Steps</font>
+<p>
+<a NAME="59"></a><font SIZE="5">An Open World Component Technology</font>
+<p>
+<a NAME="60"></a><font SIZE="4">Current Situation</font>
+<p>
+Nowadays there is no Component Technology in the Open world which is accepted by
+everyone. There exist different open source projects which are based on a component
+model, but each of them uses its own concept or technology.
+<p>
+KDE and GNOME are in the Desktop domain. Both of them are using CORBA as a
+low-level communication layer but the component models on top are completely different
+in each project. So today it is essentially impossible to write a component which can be
+used in both desktop environments. Also the current CORBA specification doesn't
+include a model for compound documents or other desktop software related functionality.
+So there are different efforts underway to overcome these problems, but they lack
+interoperability. Another issue with most CORBA implementations is that these were
+designed to run distributed network based applications using remote services. So using
+such CORBA implementation with all the network communication overhead in an
+infrastructure for a desktop component model, which in most cases will run on one local
+machine, will be in most cases the wrong approach.
+<p>
+When the Mozilla open source project started, there was a requirement to have a
+lightweight component model which could be easily ported to different platforms. So
+XPCOM was created.
+<p>
+The reasons why the OpenOffice.org suite currently employs its own component model
+are all based on these issues. Additionally, there is the requirement to provide a similar set
+of office suite functionality and technology to the widely used Microsoft products in this
+domain.
+<p>
+<a NAME="61"></a><font SIZE="4">A Short Term Solution</font>
+<p>
+As discussed above, there is no component technology available which is well accepted,
+portable and used prevalently. So to provide office functionality in different
+environments, it is necessary that different component technologies be supported.
+Supporting different component technologies is difficult but possible, but supporting
+different concepts or philosophies is quite impossible.
+<p>
+Because OpenOffice.org's component technology is able to use software bridges to access
+other components' worlds, it is possible to integrate the office components into different
+environments, such as GNOME and Mozilla. The bridging can be easily done in an
+environment where the basic concept for the components are quite similar. In any other
+case in can be very hard to provide this bridging functionality hiding all conceptual
+differences. In most cases developers and users will have to deal with the different
+concepts and philosophies. One of the annoying problems for example will be the
+different naming convention. Also if a bridge needs to deal with a complex conversion of
+arguments and calling conventions, performance issues could arise.
+<p>
+So in the near future we will provide bridges from OpenOffice.org component technology
+to XPCOM and Bonobo. OpenOffice.org components can than be used in these
+environment as integrated components.
+<p>
+<a NAME="62"></a><font SIZE="4">Vision</font>
+<p>
+The past has shown the importance of a homogenous component technology and an
+object model which integrates all software components into one easy-to-use building set.
+The use of existing building blocks in different development environments like C/C++,
+Java technology, Pyton, Perl, VB, etc. should be transparently provided by a
+component technology.
+<p>
+The object model should define the reuse of existing interfaces and components and the
+matching of concepts over a wide array of applications. It should define common base
+concepts that will be used no matter what component is being reused or what application
+is being built.
+<p>
+One challenge for the Open World will be to provide one efficient component technology
+and a homogenous, superior object model for the desktop, the office productivity suite,
+and the browser.
+<p>
+<a NAME="63"></a><font SIZE="4">Unified Component Ware</font>
+<p>
+A unified Component Technology should meet what is required for today's
+solutions.
+This will not guarantee that the technology will fulfill all future
+requirements, but it will allow the replacement of the existing solutions over time and it
+will increase acceptance by the Open World. To ensure a high level of acceptance, open
+standards should be used whenever appropriate.
+<p>
+CORBA is an open standard that is widely accepted for building heterogeneous
+distributed systems. On the other hand the CORBA specification falls short in the areas of
+compound documents and small components for personal productivity. This has changed
+to some extent with the CORBA 3.0 specification, but there are still open issues. For a
+desktop environment there is a need for support of in-process components and for local
+communication features, which are today still open to implementation in the CORBA
+environment. To the extent that these features are transparent to all components, there is
+no need for a clear specification, but in most cases today the developer of the component
+and the developer of the application using these components has to deal with this
+situation. Another problem for an open component system is the lack of a technology and
+a concept for writing cross-platform graphical components.
+<p>
+ORBit is the CORBA implementation used by most of the GNOME components. It is fast
+and lean, allowing the use of CORBA in areas that would not normally seem practical. It
+supports much of the CORBA 2.2 standard, and has hooks that allow easy integration
+with GNOME programs. ORBit provides language binding for Perl, C++, Tcl, Python,
+ADA and Eiffel, but currently not for Java technology. It allows C and C++ objects in the
+same address space to short-circuit calls (i.e. no on-the-wire marshaling) for maximum
+speed. The ORBit is a good candidate starting point for an open component technology.
+It could provide the functionality for all communication infrastructure and will allow
+interoperability with CORBA. While CORBA is an accepted standard, the ice Component
+Model provides the ability to bridge easily from one component environment to another,
+which will for example allow the usage of components in the Microsoft world. Also, the
+Mozilla XPCOM technology is a very lightweight and lean system that it could provide
+some advantages for an overall system.
+<p>
+On top of this communication and low level object infrastructure there should be a clear
+definition of interfaces for commonly used functionality, such as factories and reference-counted
+objects. There is also a requirement for a clear concept for lifetime management
+of components, activation, security and the integration into a graphical subsystems. All
+these interfaces should be designed for use in many different application domains.
+Especially for personal productivity tools and desktop environments, we need a clear
+concept and definition of interfaces to build up an infrastructure for:
+<ul>
+<li>Compound Documents and Component Reuse
+<li>Document Models
+<li>Content Storage
+<li>Monikers
+<li>Control Components
+<li>Component activation (Shared library components, process-based components and
+distributed components)
+<li>Printing</li>
+</ul>
+It is important that these specifications be useful in many application domains, and that
+standards that cover existing areas be used and supported.
+<p>
+Not every developer wants to deal with all the details of a component model. Therefore,
+to achieve acceptance, it is important to provide helper libraries for different languages
+that make the usage and the implementation of components as easy as possible.
+<p>
+<a NAME="64"></a><font SIZE="4">Outlook</font>
+<p>
+We have started an initiative for a new homogenous component technology by talking to
+several developers in different open source projects. We will work together with different
+groups to provide a leading edge component technology for a desktop environment and
+distributed applications. To the extent that standards are available and meet the
+requirements, they will be used. We would like to see the best pieces of today's existing
+technologies (e.g. Bonobo, XPCOM, UNO ...) be integrated into this technology.
+<p>
+Also we would like to start an effort with several open source projects to define the
+concept, the naming conventions and philosophy for an Open World component mode. By
+the time the component model is available it will be used by all OpenOffice.org
+components, and the OpenOffice.org API will be adapted over time to meet the
+specification of the new component model. In the future this will allow writing highly
+sophisticated applications and solutions by using existing components exclusively.
+<p>
+<a NAME="65"></a><font SIZE="5">CHAPTER 8</font>
+<br>
+<font SIZE="5">Appendix A</font>
+<p>
+<table BORDER="1" WIDTH="500">
+<tr>
+<th>Project</th>
+<th>Modules</th>
+<th>Description</th>
+</tr>
+<tr>
+<td>Xml file formats</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>xmloff</td>
+<td>Import/Exportfilter for XML</td>
+</tr>
+<tr>
+<td></td>
+<td>sax</td>
+<td>SAX UNO-components for xml-parsing and writing.</td>
+</tr>
+<tr>
+<td>L10N</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>i18n</td>
+<td>Internationalization Functionality.</td>
+</tr>
+<tr>
+<td></td>
+<td>transex3</td>
+<td>L10N Tools</td>
+</tr>
+<tr>
+<td>openoffice.org<br>wordprocessor<br>application</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>sw</td>
+<td>OpenOffice.org wordprocessor application</td>
+</tr>
+<tr>
+<td></td>
+<td>starmath</td>
+<td>OpenOffice.org math application</td>
+</tr>
+<tr>
+<td></td>
+<td>lingu</td>
+<td>Linguistics stub</td>
+</tr>
+<tr>
+<td>Openoffice.org spreadsheet application</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>sc</td>
+<td>openoffice.org spreadsheet application</td>
+</tr>
+<tr>
+<td></td>
+<td>scaddins</td>
+<td>openoffice.org spreadsheet application addins</td>
+</tr>
+<tr>
+<td>Graphic applications</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>sd</td>
+<td>OpenOffice.org drawing application</td>
+</tr>
+<tr>
+<td></td>
+<td>sch</td>
+<td>OpenOffice.org charting application</td>
+</tr>
+<tr>
+<td></td>
+<td>goodies</td>
+<td>Collection of graphic filters and 2d and 3d drawing</td>
+</tr>
+<tr>
+<td></td>
+<td>Svx</td>
+<td>Collection of graphic layers and Collection of API used by
+all OpenOffice.org Applications</td>
+</tr>
+<tr>
+<td>Database Access</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>sdb</td>
+<td>Database driver layer.</td>
+</tr>
+<tr>
+<td></td>
+<td>dbaccess</td>
+<td>Database access layer</td>
+</tr>
+<tr>
+<td></td>
+<td>connectivity</td>
+<td>OpenOffice.org Base Connectivity</td>
+</tr>
+<tr>
+<td>Porting</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>sal system abstraction layer</td>
+<td>Low level API for the integration of all supported platforms.</td>
+</tr>
+<tr>
+<td>Buildtools and Buildenvironment</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>solenv</td>
+<td>Buildenvironment tools</td>
+</tr>
+<tr>
+<td></td>
+<td>dmake</td>
+<td>Make application</td>
+</tr>
+<tr>
+<td></td>
+<td>rscpp</td>
+<td>Preprocessor for the Resource Compiler.</td>
+</tr>
+<tr>
+<td></td>
+<td>xml2cmp</td>
+<td>Processor for Uno-ComponentDescriptions</td>
+</tr>
+<tr>
+<td></td>
+<td>jtools</td>
+<td>Java technology helper applications</td>
+</tr>
+<tr>
+<td></td>
+<td>config_office</td>
+<td>Helper for buildenvironment configuration</td>
+</tr>
+<tr>
+<td>Graphic System Layer</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>vcl</td>
+<td>Visual Class Library</td>
+</tr>
+<tr>
+<td></td>
+<td>rsc</td>
+<td>Resource compiler</td>
+</tr>
+<tr>
+<td></td>
+<td>toolkit</td>
+<td>VCL Implementation of the UNO Toolkit and the UNO Controls</td>
+</tr>
+<tr>
+<td></td>
+<td>UnoControls</td>
+<td>UNO controls</td>
+</tr>
+<tr>
+<td></td>
+<td>forms</td>
+<td>Forms implementation</td>
+</tr>
+<tr>
+<td>Printing</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>xprinter</td>
+<td>Stubs for the Bristol X-Printer</td>
+</tr>
+<tr>
+<td>Scripting Engines</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>basic</td>
+<td>Basic interpreter and the basic runtime library</td>
+</tr>
+<tr>
+<td></td>
+<td>basctrl</td>
+<td>Basic IDE</td>
+</tr>
+<tr>
+<td>Utilities</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>tools</td>
+<td>Common used base classes (string, date, time, streams, ...)</td>
+</tr>
+<tr>
+<td></td>
+<td>svtools</td>
+<td>Collection of Patterns and help classes</td>
+</tr>
+<tr>
+<td></td>
+<td>std2</td>
+<td>STL port - a derivative from the SGI/STL.</td>
+</tr>
+<tr>
+<td></td>
+<td>io</td>
+<td>UNO I/O services</td>
+</tr>
+<tr>
+<td></td>
+<td>eventattacher</td>
+<td>Component based event handling</td>
+</tr>
+<tr>
+<td></td>
+<td>unzip</td>
+<td>Compression library</td>
+</tr>
+<tr>
+<td></td>
+<td>unotools</td>
+<td>UNO helper classes</td>
+</tr>
+<tr>
+<td></td>
+<td>extensions</td>
+<td>Additional components</td>
+</tr>
+<tr>
+<td></td>
+<td>external</td>
+<td>External references</td>
+</tr>
+<tr>
+<td></td>
+<td>configmgr</td>
+<td>Configuration management</td>
+</tr>
+<tr>
+<td></td>
+<td>sot</td>
+<td>Compatible storage implementation.</td>
+</tr>
+<tr>
+<td>Installation</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>setup2</td>
+<td>Setup Application</td>
+</tr>
+<tr>
+<td></td>
+<td>scp</td>
+<td>Packaging scripts</td>
+</tr>
+ <tr>
+<td></td>
+<tr>
+<td></td>
+<td>Scptools</td>
+<td>Packaging tools</td>
+</tr>
+<tr>
+<td></td>
+<td>Instsetoo</td>
+<td>Installation set creation</td>
+</tr>
+<tr>
+<td></td>
+<td>Readlicense</td>
+<td>Readme and license texts</td>
+</tr>
+<tr>
+<td></td>
+<td>Extras</td>
+<td>Demo documents, help files, resources...</td>
+</tr>
+<tr>
+<td></td>
+<td>Wizards</td>
+<td>Wizards</td>
+</tr>
+<tr>
+<td>UCB (Universal Content Broker)</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>chaos</td>
+<td>Universal Content Broker</td>
+</tr>
+<tr>
+<td></td>
+<td>inet</td>
+<td>Internet transport protocols (FTP, HTTP, LDAP, IMAP, NNTP, POP3, SMTP).</td>
+</tr>
+<tr>
+<td></td>
+<td>uui</td>
+<td>UCB Graphical User Interface Components</td>
+</tr>
+<tr>
+<td></td>
+<td>ucbhelper</td>
+<td>Helper classes for UCB users and Content Provider implementers</td>
+</tr>
+<tr>
+<td></td>
+<td>store</td>
+<td>Reliable, recoverable storage filesystem</td>
+</tr>
+<tr>
+<td></td>
+<td>ldapber</td>
+<td></td>
+</tr>
+<tr>
+<td>StarOffice API</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>api</td>
+<td>IDL definitions of all interfaces of the OpenOffice.org API</td>
+</tr>
+<tr>
+<td></td>
+<td>offuh</td>
+<td>Generates UNO headers.</td>
+</tr>
+<tr>
+<td>UDK (Uno
+Development
+Kit) /
+Componenet
+Technology</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>cppu</td>
+<td>C++ UNO core, C++ bridges</td>
+</tr>
+<tr>
+<td></td>
+<td>unoidl</td>
+<td>Interface Definition Language compiler.</td>
+</tr>
+<tr>
+<td></td>
+<td>cppuhelper</td>
+<td>C++ UNO implementation helpers</td>
+</tr>
+<tr>
+<td></td>
+<td>javaunohelper</td>
+<td>Java technology Uno helper implementations</td>
+</tr>
+<tr>
+<td></td>
+<td>jurt</td>
+<td>Java technology UNO Runtime</td>
+</tr>
+<tr>
+<td></td>
+<td>bridges</td>
+<td>UNO bridges from any language</td>
+</tr>
+<tr>
+<td></td>
+<td>remotebridges</td>
+<td>UNO interprocess bridges</td>
+</tr>
+<tr>
+<td></td>
+<td>stoc</td>
+<td>OpenOffice.org components - basic UNO services</td>
+</tr>
+<tr>
+<td></td>
+<td>cpputools</td>
+<td>Collection of UNO utility and runtime programs</td>
+</tr>
+<tr>
+<td></td>
+<td>registry</td>
+<td>Registry</td>
+</tr>
+<tr>
+<td></td>
+<td>codemaker</td>
+<td>IDL compiler backend</td>
+</tr>
+<tr>
+<td></td>
+<td>rdbmaker</td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>vos</td>
+<td>Object orientated Framework above sal. This module encapsulates sal in C++ classes for ease of use.</td>
+</tr>
+<tr>
+<td>Object Integration</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>So3</td>
+<td>Compound document implementation</td>
+</tr>
+<tr>
+<td></td>
+<td>Sj2</td>
+<td>Integration of embedded objects</td>
+</tr>
+<tr>
+<td></td>
+<td>Ie</td>
+<td>Integration of internet explorer</td>
+</tr>
+<tr>
+<td>Application Framework</td>
+<td></td>
+<td></td>
+</tr>
+<tr>
+<td></td>
+<td>Sfx2</td>
+<td>Application framework</td>
+</tr>
+<tr>
+<td></td>
+<td>offmgr</td>
+<td>Database components</td>
+</tr>
+<tr>
+<td></td>
+<td>res</td>
+<td>Bitmap resources</td>
+</tr>
+<tr>
+<td></td>
+<td>idl</td>
+<td>IDL compiler for the resources.</td>
+</tr>
+<tr>
+<td></td>
+<td>framework</td>
+<td>Provides Frames Hierarchy for logical managing of components/documents.</td>
+</tr>
+<tr>
+<td></td>
+<td>desktop</td>
+<td>OpenOffice.org (desktop) application</td>
+</tr>
+<tr>
+<td></td>
+<td>DocumentProperties</td>
+<td>Document properties handling</td>
+</tr>
+</table><p></p>
+</body>
+</html>