| <!DOCTYPE html> |
| <html><head> |
| <title>Main Design Goals</title> |
| <meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8"> |
| </head> |
| <body> |
| <h2>Main Design Goals</h2> |
| |
| <p> |
| This API is version independent, scalable, durable, and reusable. And because |
| it is implemented using the OpenOffice.org component technology, it is |
| programming language independent as well. |
| </p> |
| |
| <p> |
| It has to be seen more like an independent specification than being |
| dependent on a preexisting implementation. Therefore it is our to keep all |
| component APIs in this project and to keep all implementation code out of |
| this project. |
| </p> |
| |
| <p> |
| Its version independence and durability results from the fact that we limit |
| changes to the API. You can add interfaces, services, and so on to the |
| OpenOffice.org API. However, other changes are rather limited: |
| </p> |
| |
| <ul> |
| <li>Interfaces, structures, and exceptions are not allowed to change at all, |
| this breaks the existing code immediately.</li> |
| <li>Enums are not allowed to change, this breaks the existing Java code.</li> |
| <li>Services specifications can be changed restricted (optional extensions).</li> |
| <li>Constants can be add constants to constant groups, but changing |
| the value of a constant or remove a constant is not allowed, this would |
| break existing code as well.</li> |
| </ul> |
| |
| <p>Its scalability and reuseability results from our design pattern, to |
| approach an orthogonal architecture rather than having specialized interfaces |
| for certain requirements. For example does each interfaces only cover exactly |
| one aspect of the behaviour of an object. |
| </p> |
| </body> |
| </html> |
| |
