Fwd: The first alpha version of "Common DesktopInfrastructure" is released

[Sebastian Sauer]

George Staikos wrote:
> 
> Hi everyone,
> 
>    Daisuke has asked for some feedback on his proposal.  I think the
> KDE community in general should provide feedback.
 
Some comments that slipped into my mind while reading the 
http://www.smg.co.jp/opensource/CommonDesktopInfrastructure/products/Architecture 
Design Document.pdf without looking at the sourcecode;

> 1.3.2 Non-Functional Requirements
> (3) It is unnecessary to change the specification of the existing component 
technologies.
> 2.1 Since realizing the protocol conversion without changing the existing 
component technologies is required, protocol conversion parts are realized in 
the exterior of the existing components.

I am not sure I understand this point. If it does mean, that each application 
needs to have additional code, it's a blocker for any kind of adoption since;
1. It puts the work to implement and even more important to maintain the 
additional code on to the shoulder of each application that would like to 
implement such functionality.
2. I doubt that developers will make this a high priority and that means that 
as long as nobody does provide implementations for _all_ applications we have 
the very same situation like now with the difference, that there are already 
a wide range of applications that implement DBus while there is no 
application that does implement the "Common Desktop Infrastructur" (yet?). 
IIRC at least OpenOffice.org already sayed that they will stick with UNO and 
don't support DBus any time soon. So, why should they change there mind here 
with this protocol specialy taken into account that DBus is more widly used 
(yet)?
3. Even if someone cames up with implementations for all applications it's 
totaly another question if the patches got accepted since additional code 
means additional maintaining-work.
4. Why should someone choose those protocol rather then e.g. DBus direct?

If I got that point wrong then it would be at least great to explicit name, 
that it does not mean any additional work for application-developers since 
that's a very important point imho.

> 2.1 Converting RPC Protocol
> The caller protocol converts into the callee protocol via conversion to 
abstract protocol.

I am not sure there what that may mean. Do we have then a roundtrip of e.g. 
DBus<=>Abstract Protocol<=>UNO ? and if yes, why not just have DBus<=>UNO? 
Guess I just fail here to see what the abstract protocol does provide in 
addition since those protocol would also need bridges to other protocols, or?

> 2.1.1 
> So, only synchronous call is adopted as the common RPC protocol of Common 
Desktop Infrastructure this time.
> However, when remarkable performance deterioration occures by adopting 
synchronous function call, it is
> necessary to change common RPC protocol to asynchronous function call. 
Therefore, it is necessary to verify
> performance in advance.

This can be also a problem since that means, that the caller either blocks 
till the callee decides to response or have to wait for a timeout. Any try to 
work around this means again additional work for application-developers like 
putting the whole thing into an own thread and additional work is something a 
lot of people don't like ;)

Regarding performance, I like to provide a sample here. KWord 2.0 does come 
with a python-script (using Kross, heh) that does IPC-connect with 
OpenOffice.org. While this should be at least theoretical faster then RPC 
(specialy taken into account, that RPC could also mean _real_ remote as in 
over the internet or another slow connection), it is still very slow if 
expensive operations are done like letting OpenOffice.org read e.g. a huge 
non-ISO MSOOXML-document and to pass it on to KWord as e.g. ISO-OpenDocument. 
Also UNO itself is network-aware what may mean, that even those 
IPC-connection is done over an ISDN-connection. In any case blocking is very 
dirty here since how to provide feedback to the user about what is going on 
at the moment and how much of the work was already done?

DBus does take this already into account and allows to choose if the call 
should be done sync or asynch and therefore saves each application-developer 
the work for additional code.

> 2.2.3
> When RPC Routing Service of a Component wasn't started, it is necessary to 
activate it.

and what happens if this fails cause e.g. the application isn't running or 
cause the application is running without a "listener" that waits for such 
requests? e.g. iirc OpenOffice.org does per default not startup 
the "UNO-server" (or UNO-listener however you like to name it) since most 
users just don't need it and therefore it's not needed to increase the 
Openoffice.org startup-time even more. Seems QtDBus is doing something 
similar to this.

> 2.7 Code generator
> the threshold of initial introduction can be lowered.

Code generation can be a good thing but it also has it's downside: missing 
flexibility. So, it's not that easy to create things on demand aka 
on-the-fly. Both, QtDBus with it's QDBusAbstractAdaptor and the dirty way to 
manipulate the Qt-metasystem on the fly as well as the very flexible but damn 
complicated UNO, do take this into account and are allowing both ways.