Hello Kay,
>Daisuke Kameda wrote:
>>> 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
>>
>> What do you think better solution for realizing interoperability?
>
>if I wanted to achieve interoperability between e.g. Uno and D-Bus, I
>would at first implement a bridge between these two, than I would look
>at the used "interfaces" and would try to identify semantically
>equivalent ones and would implement "adapters" between any pair of
>interfaces needed, likely in one of the Uno supported languages, e.g. C
>or C++.
I agree with "at first implement a bridge between these".
But, I want to realize interoperability between at least four component
technologies, such as UNO, XPCOM. If you implement bridge between these,
you would have to implement three bridges.
I think that this complicate the interoperability problem.
So, I think that introducing "common protocol" is better.
What do you think this point?
>>> We intend to introduce abstract components as "shared" interface.
>>> I think that it is the best solution, now.
>>
>> I think that it is possible to define "share" interface like ODF.
>> Do you think that it is possible?
>
>I fear the scope of something like ODF is to narrow, you likely also
>want to "map" more basic types/interfaces, such as "Input/OutputStream",
>"HashMap" etc.
Your opinion is exactly. But, introducing detailed types/interfaces
complicate the architecture. So, we should discuss about really necessary
types/interfaces for deciding.
>> I think that it is better to practice these "a huge amount of work"
>> in Potland project.
>I doubt that the Portland project is stuffed for such a project.
Why you doubt it?
I believe that it accord with Portland project vision.
>> If you agree that these works is necessary, what do you think to
>> perform it better?
>>
>The perfect solution would harmonize the requested projects, though
>theoretically possible, this is unlikely to happen (I did some brief
>investigations into this some years ago :-). One more reasonable
>approach seems to be, to select one component model and to add adapters
>as needed.
It is sure reasonable, but it is very difficult to choose one component
technology.
--
Daisuke Kameda
Japan KDE Users' Group: President
mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] http://www.smg.co.jp/
http://www.smg.co.jp/opensource/CommonDesktopInfrastructure/
_______________________________________________
Desktop_architects mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/desktop_architects
