[Desktop_architects] [Announce] "Common Desktop Infrastructure" 0.1.0 is released

[Daisuke Kameda]

I sent the mail.

But, I couldn't get the mail, although there is it in
desktop-architect archives.

So, I send this mail. If you get twice this mail,
I apologize to you.

Kay Ramme is wrote:
> I see that the big desktop programs (GNOME / KDE, Firefox,
> OpenOffice.org, Thunderbird) have an interoperability problem.
>
> They all bring their own infrastructure (system abstraction,
> component model, scripting language, VFS, font management,
> widget set, XML parser / emitter, 2D / 3D engines, standard dialogs,
> configuration, APIs, etc.) while they basically only differ
> in their application(s).
>
> Because of this, it is basically hard to create an integrating
> solution using this or that from these or other applications.
> On Windows you may use COM or .Net which more or less is available
> for most applications (even OOo ;-), as well as being supported
> by all kinds of companies developing components for various
> purposes. IMHO, this is a strength of Windows.

I agree with your view.

> If I understand you correctly, you are proposing a new
> protocol/component model to be used to mediate between the established
> ones, using "protocol converters" to achieve interoperability.

Exactly. If I add note, protocol/component model which we have proposed
is little low level.


> Actually, OpenOffice.org's component model (Uno) was originally
> envisioned to be exactly this, using so called "bridges" to mediate
> between different languages, component models and protocols. This has
> been achieved to some extent, e.g. there are bridges for Uno/RPC,
> Java, OOo BASIC, Windows COM, C, various C++ ABIs, CLI (.Net),
> Python and even experimental ones for Perl, TCL and XPCOM (there even
> was a very experimental one for web services :-). That actually means,
> that you could use Windows VBA on a Windows box to call on XPCOM
> objects being instantiated on a Linux system.

I know almost about this, because we had researched about various
component technologies :-)

Perhaps you know this, if I add explanation, our idea differ from
"bridge" model. We intend to introduce the new low level
component/protocol model, and introduce "protocol converter"
(nearly equal "bridge") for mutual converting the new model
and existing technologies


> Unfortunately there is not only a lack of an "interoperable ABI" (the
> mediator between the programs component models), but also a lack of
> "shared" interfaces. It is quite unlikely, that you find any
> reasonableUno object in OOo which may be syntactically compatible
>  (has a compatible interface) to be passed e.g. to an XPCOM object,
> and even if there is a syntactically compatible one, than it is likely
> semantically incompatible.

We intend to introduce abstract components as "shared" interface.
I think that it is the best solution, now.

> This does not mean, that the interoperability problem is unsolvable,
> it is "just" a huge amount of work.

Yes. It is very, very huge work.
But, I think that it is necessary for opensource desktop.

-- 
Daisuke Kameda
  Japan KDE Users' Group:  President
    mailto:daisuke at kde.gr.jp  http://www.kde.gr.jp/~daisuke/
  immodule for Qt Project:  Project Maintainer
    http://www.freedesktop.org/wiki/Software_2fimmodule_2dqt
  SMG Co., Ltd.:  Engineering Creator
    mailto:kameda at smg.co.jp  http://www.smg.co.jp/
    http://www.smg.co.jp/opensource/CommonDesktopInfrastructure/