> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Shaver Sent: Monday, December 19, 2005 9:16 AM To: Martin Konold Cc: desktop_architects@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
_______________________________________________ Desktop_architects mailing list Desktop_architects@lists.osdl.org https://lists.osdl.org/mailman/listinfo/desktop_architects