[Portland] Fallbacks

[Lubos Lunak]

 Fallbacks, i.e. how to handle the cases when no daemon is present at all or 
when it is present but it doesn't provide all needed functionality. There are 
basically these possible solutions:

- Every call has return value for "failed", the lib API returns it to the app, 
the app finds out the call failed and takes care of falling back itself. 
Simple for everybody except for the app. Currently not that bad for apps 
though, as these days they have "fallbacks" for everything. Still, that'd 
mean no shared implementation, resulting in many possibly in various ways 
broken implementations.

- Every call has return value for "failed", the lib itself takes care of 
falling back. The problem here is the risk of dragging in too many 
dependencies in the library that'd be needed for implementing all the 
functionality for the fallbacks. As such this option is probably not viable. 
A better option might be mixing these two options, i.e. implementing simple 
callbacks in the library and returning to the app with failure for more 
complicated things. Another possibility might be the library using some 
additional binary that'd avoid the linking, but then that'd be probably just 
a worse variant of the following.

- The app is also accompanied by its own daemon to which the app falls back if 
the desktop's daemon cannot be found. Handling of the falling back should be 
handled by the library, the app would just do something like 
setFallbackName( "fooapp_from_fooinc"), the library would first try the 
normal communication (socket name) and if that fails it'd launch the app's 
daemon that'd have a specific communication (its own socket name). This is 
IMHO the best option, there will be a generic daemon that'd app developers 
could ship with their apps, possibly even changing some of the functionality 
to better fit their app (changes as in changing the default web browser, not 
big changes as it'd still have to be compatible).

 This case still has a problem when the desktop provides only a daemon that 
doesn't provide all required functionality (i.e. usually a daemon that's too 
old). Partially falling back doesn't seem like good choice to me - some 
things may require to be completely handled by one daemon (say that the 
desktop's daemon provides only download() but not upload() - doing one 
operation in one daemon and the second one in the other one may leave 
temporary files around or cause concurrency problems). As desktops, unlike 
apps, generally shouldn't lag behind and should within reasonable time 
provide all new functionality it seems just checking all needed functionality 
first and falling back completely to private daemon should do. People running 
old desktops will have to upgrade or won't get full functionality.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/