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
_______________________________________________
Desktop_architects mailing list
Desktop_architects@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/desktop_architects
