Function areas of similar structures have access to the same interfaces, so that the programmer can easily feel at home in the component world. Platform Independent It is specified to be platform independent and is available on all platforms that run OpenOffice.
Network Able 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. CHAPTER 4 Openness 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. 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.
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.
While the component technology determines how the components or applications communicate with each other, the OpenOffice. This interface structure is very important in determining the degree to which re-application of a development is possible. The interfaces defined by the OpenOffice. They are version independent and scalable.
They are durable. They are re-applicable. Rather, it has been designed from the viewpoint of application and component developers. It offers programming interfaces for nearly all OpenOffice. Application Areas There are multiple ways to use OpenOffice. First, there is the typical macro programming for running certain tasks automatically.
Secondly, parts of OpenOffice. A more advanced application is to modify OpenOffice. A very interesting application area is to replace the user interface of OpenOffice. Design Principles Some principles that are important in all our designs are: orthogonality The API consists of interfaces which can easily be combined to serve special needs of certain objects.
Developers can always start with a minimum set of interfaces and add more step by step to embody more features. Remote usability Services can be used efficiently from different processes or even different machines. 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. Object Model The OpenOffice. Therefore the OpenOffice. For other languages, only a language binding needs to be provided to access the whole OpenOffice.
The API is made up by following stereotypes: implementation classes 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. 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.
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.
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. Exceptions are used for error handling just as in the Java technology.
In the Java technology, both are represented as classes with constant data members. 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. 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.
A container allows replacement, insertion and removal of these sub-objects. A wide variety of predefined interfaces is available for this design pattern. Cursors in text play an especially major role, because indexing of text is not reasonable. Supplier To access structural but optional data members, we frequently offer supplier interfaces which in many cases only have one get method.
Events 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. Exceptions for Error Handling Exceptions constitute our principal error handling concept.
For asynchronous calls, exceptions are transferred in callback events. Module Categories The OpenOffice. For text documents, spreadsheet documents, drawing and presentation documents integration framework These interfaces make it possible to integrate new components into OpenOffice. Summary The results and benefits of the OpenOffice. One can build new applications from components without modifying source code.
One can use a familiar programming language. A first release of a Development Kit, containing support of the OpenOffice. This is because the whole technology is based on a platform-independent approach.
This acts as an abstraction layer for the upper software components. This allows to port the OpenOffice. The decision for an object oriented language gives the OpenOffice. The following information will give just a rough overview over the overall architecture. Some components of the OpenOffice. Many parts of the OpenOffice. In many cases one block in the architecture is covered by more than five CVS modules in the source tree.
Layered architecture The whole architecture is based on a layered approach. There are four defined layers where each covers a special area of the functionality. System Abstraction Layer This layer encapsulates all system specific APIs and provide a consistent object oriented API to access system resources in a platform independent manner.
Infrastructure Layer 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.
Framework Layer 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 Application Layer All OpenOffice.
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. 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. 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. Operating system layer 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.
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. Runtime library 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. Standard Template library As a generic container library the standard template library is used.
It supplies implementations for list, queues, stacks, maps, etc. Visual Class library The visual class library is one of the core libraries of the OpenOffice. 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.
These range from something as easy as donating to the Apache Software Foundation, or participating in mailing lists, to actually contributing code for the product. To contribute to volunteer with the Openoffice project user or developer web sites or product , please subscribe to the Apache Openoffice developer mailing list to get started.
Much of the excitement of an Open Source site takes place in the mailing lists. These are public. All our major lists are public. What you post to these is on the public Internet. We suggest you do not post private information and keep in mind the public and persistent nature of all that you write to the lists. For questions having to do with the Apache OpenOffice product , please use our "users" list: users-subscribe openoffice.
Besides that list, we have two general lists: our "announce" list, which is for major announcements and has little traffic, and the "dev" list, which is for general discussions related to the project and is fairly heavily trafficked.
To subscribe to any of these lists, click on the appropriate link below and send the email message. Leave the subject line and body empty. Together with our product, the OpenOffice brand is spread over the world and we need your cooperation so that it is applied consistently. The OpenOffice logo and the seagulls are well recognized.
This section is meant to provide information on using the OpenOffice logos and banners for those interested in linking to us or distributing OpenOffice as CDs, or via a download mirror. Please review the Apache OpenOffice Trademarks page for further information and to request to use the logo in any form or fashion. By Steven J. The company then claims that Oracle is doing this to "demonstrate its commitment to the developer and open source communities.
The Apache Software Foundation 's model makes it possible for commercial and individual volunteer contributors to collaborate on open source product development.
We look forward to engaging with other community members to advance the technology beginning with our strong support of the incubation process for OpenOffice at Apache. As well IBM should. On the Apache side, Jim Jagielski, president of the Apache Software Foundation, and proposed mentor for Apache OpenOffice, said, "We welcome highly-focused, emerging projects from individual contributors, as well as those with robust developer communities, global user bases, and strong corporate backing.
At first, Apache tells me, OpenOffice will be an "incubating project" or "podling. That's licensing part could be be a bit of a problem. It's not entirely compatible with the Apache License 2. Jagielski tells me though that there shouldn't be any intellectual property IP problems. All code copyrighted by Oracle is now relicensed under AL2. The ASF has never required copyright assignment.
0コメント