[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