Kameda-san,
Daisuke Kameda wrote:
>
> 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.
As far as I can tell, you have to do that anyway. You need a "super"
protocol to which you "bridge" the other ones (Uno, XPCOM, ...). That
means one bridge from any protocol to the "super" protocol. After that
you can "bridge" from any protocol to any other by chaining any two
bridges. And this is exactly how Uno currently does bridging from e.g.
VBA to XPCOM.
>
> I think that this complicate the interoperability problem.
> So, I think that introducing "common protocol" is better.
> What do you think this point?
As said above, the "common protocol" is more or less just another
"component model".
>
>
>>>> 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.
Agreed!
>
>
>>> 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.
Somebody involved in the Portland project (Waldo?) may enlighten us here
... :-)
>
>
>> 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.
>
It is. If I was in charge of it, I would create a table listening the
features of the different available component models to the select the
one best suited.
Regards
Kay
--
Sun Microsystems GmbH Kay Ramme
Sachsenfeld 4 Senior Technical Architect
20097 Hamburg Phone: (+49 40) 23646 982
Germany Fax: (+49 40) 23646 550
http://www.sun.com/staroffice mailto:[EMAIL PROTECTED]
http://www.sun.com/openoffice
http://udk.openoffice.org
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring
_______________________________________________
Desktop_architects mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/desktop_architects
