Filtry importujące dokumenty do OpenOffice automatycznie tworzą odpowiednie struktury wewnętrzne danego programu. Prawdopodobnie niedługo pojawi się inny sposób importu - moduły transformujące do postaci XML (wykorzystując m.in. XSLT). Autorzy mają także stworzyć bardzo dokładny moduł importujący dokumenty XHTML do edytora Writer tak, by można było traktować XHTML niemal jako "rodzimy" format OpenOffice.

Powstało wiele przykładowych aplikacji, które na podstawie dokumentów OO automatycznie generują HTML. Jedna z ciekawszych wykorzystuje tylko Perl i bibliotekę AxKit - w ogóle nie jest potrzebna instalacja OO, by utworzyć HTML.

Wielka bolączka - StarBasic

Microsoft Office to nie tylko pakiet biurowy, ale platforma, na podstawie której można tworzyć małe aplikacje wspierające działanie firm. Takiego mechanizmu brakuje w OpenOffice. Język Basic, który ma służyć do pisania makr, ma ograniczone możliwości. Do niektórych funkcji nie można uzyskać dostępu z poziomu innych programów niż OO.

Edytor, w którym są pisane makra, pozostawia wiele do życzenia. Brak mechanizmu podpowiadania składni i przeglądarki obiektów. Praktycznie użytkownik jest skazany na żmudne przeszu- kiwanie dokumentacji, sięganie do źródeł i wpisywanie kodu. Nawet w najnowszej wersji 1.0.1 nie ma mechanizmu nagrywania makr. Zresztą makra OO można porównać do ubogich rozwiązań WordBasic w prastarym Word 95.

W tej sytuacji trudno oczekiwać, by powstawały licznie aplikacje bazujące na mechanizmie makr OO.

UNO

Jednak mocną stroną OO jest architektura. Niewykluczone że dzięki temu będą powstawać programy, w których OO zostanie osadzony w większym systemie informatycznym i wykorzystany np. jako edytor tekstowy czy arkusz kalkulacyjny umożliwiający dodatkowe manipulowanie tworzonymi raportami.

Architektura OO 1.0 jest oparta na modelu obiektów Universal Network Object - UNO. To model opracowany na potrzeby technologii SunOne Webtop. Głównym celem UNO jest zapewnienie współpracy między aplikacjami napisanymi w różnych językach programowania, przy założeniu różnych modeli obiektowych, działających w różnych architekturach. Co prawda model komponentowy był oryginalnie projektowany do pracy zdalnej, ale powstała specyfikacja, która pozwala efektywnie wywoływać obiekty lokalnie.

Każdy komponent działa w ramach środowiska Uno Runtime Environment (URE). Jest ono definiowane dla każdego języka (obecnie Java i C++). Jeżeli odwołanie odbywa się między komponentami napisanymi w tym samym języku, to następuje wywołanie funkcji wirtualnej (praktycznie narzut związany z modelem komponentowym jest minimalny). W przypadku wywołań między różnymi językami translacją zajmuje się biblioteka UNO. Z pewnymi ograniczeniami można także przekazywać wyjątki. Nie są potrzebne żadne pośrednie procedury typu stub/proxy, jak np. w technologii CORBA.

W UNO, podobnie jak w CORBA czy COM, obok właściwego pliku z implementacją musi być zdefiniowany dokument IDL, określający interfejs. IDL przypomina analogiczny dokument CORBA, jednak w przeciwieństwie do tamtego obsługuje definicje wyjątków i może wskazywać "czas życia" obiektów. Nie ma natomiast wielokrotnego dziedziczenia interfejsów ani przekazywania tablic jako "obszarów" pamięci.

Na bazie możliwości, jakie dają komponenty UNO, zdefiniowano API Open-Office i powstał Office Development Kit (ODK), który pozwala rozszerzać OO o dodatkowe moduły pisane w Javie lub C++. Basic wbudowany w OO korzysta ze specjalnego interfejsu dla języków skryptowych i odwołuje się do odpowiednich interfejsów UNO. Równocześnie nic nie stoi na przeszkodzie, by z UNO korzystały inne aplikacje "nadbudowane" na OO. Warto dodać, że komponenty UNO mogą być "opakowane" i udostępnione jako JavaBeans (duża część funkcjonalności bazowego API OO jest dostępna jako obiekty w Javie i może być bez problemu wykorzystana w tym języku).

Dane

Twórcy OO nie planują na razie opracowania aplikacji zbliżonej możliwościami do Microsoft Access. Może to być spowodowane faktem, że płatna wersja StarOffice zawiera już prosty moduł oparty na Adabas, za pomocą którego tworzy się interfejsy do bazy danych.

Na potrzeby OO opracowano specyfikację interfejsu dostępowego. Konstrukcją przypomina on API JDBC. Dostępne są również interfejsy pośrednie - w OO można skorzystać ze źródeł danych ODBC, JDBC i ADO. Powstały "rodzime" moduły obsługi baz dBase i CVS (niezbyt szybki), a także Adabas. Planowany jest również sterownik dla My SQL.

Równocześnie powstają specjalne moduły - forms i svx, które mają maksymalnie uprościć tworzenie interfejsu do danych w OO.

Dokumentacja...

Podstawową wadą OpenOffice jest dokumentacja "developerska". Dotyczy to zwłaszcza dokumentacji makr w StarBasic czy opisu interfejsów API. Trudno się obejść bez czytania źródeł programu.

Obecnie jest to jeden z priorytetów projektu OO. Dokumentacja bazowych interfejsów jest tworzona w podobny sposób, co JavaDoc - w pliku IDL znajdują się komentarze, z których są generowane odpowiednie strony HTML. Na dłuższą metę to nie wystarczy. Miejmy nadzieję, że twórcy OO pójdą w ślad Microsoftu i z czasem przygotują coś na kształt OpenOffice Resource Kit.