component models and API in the open source world
- From: Michael Hoennig "(mi)" <mi sun com>
- To: gnome-components-list gnome org
- Subject: component models and API in the open source world
- Date: Mon, 16 Oct 2000 15:47:27 GMT
Hello everybody on this list,
after I'm lurking on this mailing list for a while now, I'd like to
introduce myself:
I'm an employee of Sun Microsystems working on StarOffice for over ten
years now. My current responsibility has been the design of the
StarOffice (now OpenOffice) API - more exactly the external API specified
on CORBA like IDL files. Previous to that I was responsible for the
design and implementation of the C++ component framework on which all
StarOffice applications are build (not to confuse with the UI toolkit).
My personal (and indeed it's not everybodies here at Sun) opinion is that
the open source world should concentrate on common APIs. This is really a
big pro within the proprietary Microsoft world: There you have COM/DCOM
and a single set of interfaces. We should try to get to this ideal of a
homogenous world of interfaces as well. I did not say their interfaces
itself were ideal!
Being a GNOME user myself, I really like the GNOME approach. Thus I would
appreciate it very much, if we (GNOME/BONOBO and OpenOffice) could work
together and converge our APIs. Actually there are two areas which are
somewhat related: 1st the underlying component technology, 2nd the APIs.
I think, we should address both areas, but I'm mainly speaking about the
API first because the API is harder to change, once there are many
applications built on.
Fortunately the OpenOffice API, which BTW you can find at
http://api.openoffice.org, has almost no interfaces for building compound
documents which on the other hand is the strength of BONOBO.
Unfortunately there are some differences: For example the naming
conventions; or that the OpenOffice API is using a stereotype "service"
to specifiy an abstract objects behaviour (a service combines interfaces
and properties); or some low-level interfaces which are different. But
hopefully we can find migration paths for all these difference. Too bad,
I missed Miguel de Icaza visited our office here in Hamburg, Germany.
I hope that I'm not alone with my wish of migrating our APIs. What is
your opinion about this?
Michael
--
I'm speaking for myself, I'm not speaking for my employer.
I'm a weirdo anyway.
I'm Mi ;-)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]