[Desktop_architects] Runtime dependency limitations

Brooks, Phil phil_brooks at mentor.com
Mon Dec 19 09:29:00 PST 2005


 
> ISVs are going to _want_ to have the ability to control which  
> optional bits they call into, and what their fallback pattern is, I  
> predict.  If we don't have a GNOME file picker available, f.e., we  
> use our XUL one.  Bringing up a GTK1-era file-selection-bag-of- 
> widgets instead would make us frown, or even use coarse language.

ISVs would prefer not to fiddle with anything that is optional or
implemented in more than one way depending upon choices that the
user made (i.e. which distro is loaded, which desktop is running
etc.)

As to whether Rudi is the answer to this, it depends upon how 
complicated it is to use and how reliable in practice.

Phil

-----Original Message-----
From: desktop_architects-bounces at lists.osdl.org
[mailto:desktop_architects-bounces at lists.osdl.org] On Behalf Of Mike
Shaver
Sent: Monday, December 19, 2005 9:16 AM
To: Martin Konold
Cc: desktop_architects at lists.osdl.org
Subject: Re: [Desktop_architects] Runtime dependency limitations

On 19-Dec-05, at 12:43 AM, Martin Konold wrote:

> Useing something like DT_USEFUL would put a lot of complexity in  
> the code of
> the ISVs in order to handle all possible combinations of available
> libraries/versions.

Is that something that has been seen in practice with similar systems?

> This is a boring, error prone and repeated task for every ISV.

To the extent that each ISV may well want to decide which pieces are  
optional and not, as dictated by their product goals, yes.  It turns  
out that you can almost certainly hide a lot of the symbol stuff with  
easy inline functions or macros to just return an error  
(distinguished or otherwise) if the optional symbol is missing, so  
it's not much harder to work with than just writing to the new APIs  
and having decent error checking.  In richer environments, like Mono  
or Python or whatnot, I imagine that it's even easier.

ISVs are going to _want_ to have the ability to control which  
optional bits they call into, and what their fallback pattern is, I  
predict.  If we don't have a GNOME file picker available, f.e., we  
use our XUL one.  Bringing up a GTK1-era file-selection-bag-of- 
widgets instead would make us frown, or even use coarse language.

> IMHO the RUDI approach allows to share this effort in an efficient  
> manner as
> the ISVs don't have to care much about than simply using it.

I think I need to understand RUDI better to appreciate what the  
benefits are in exchange for requiring apps to go through DBUS and  
XML (or some such?) to get a file dialog open.  And I already have a  
fair bit of XML stuff at my disposal, perhaps unlike many other ISVs.

Searching for information on Google so far has resulted in only a  
very high-level overview and vision document and a mindmap, possibly  
because "Rudi" also seems to be the name of a KDE beta release. (!)

Is there some doc describing, concretely, what specific problems are  
solved by RUDI, and at what cost?  That would help me immensely in  
understanding exactly what path is being proposed here.

Mike





More information about the Desktop_architects mailing list