[Portland] Proposal: Rework the current xdg-utils. (with implementation details)

[Zhe Su]

As an application developer, calling a shell script inside an application to
do something is really bad. For example, my application needs open url or
local file by external applications, currently there is only way to do it:
execute xdg-open shell script by using system() or exec() system call. But
this approach has many limitations, such as, it's impossible to know if and
when the application is started successfully. And it might has security
issues.

Using dbus approach, any applications can invoke the methods and get
feedback in native code very easily. And as dbus is already a freedesktop
standard, every modern Linux distributions (even OpenSolaris) bundle dbus by
default. I don't think it's over-killed here.

Remember, dbus is not only for GNOME and KDE.

Regards
James Su

2008/11/11 洪任諭 <pcman.tw at gmail.com>

> Shouldn't dbus being slightly over-kill here?
> If simple scripts can do it, using dbus here only brings complexity.
> Besides, currently there are many "org.gnome.xxxx" services which I
> don't think KDE will adopt.
> Moreover, if we choose this approach, that means, all desktop
> environments which want to be compatible with freedesktop.org/portland
> will have to depend on dbus and create dbus services.
> I don't think most of the authors of lightweight desktops will agree
> on this, hence this can inhibit the spreading of freedesktop.org
> specs.
> Cross-desktop doesn't means "making GNOME and KDE talk to each other".
> There are still many other desktop environments for different needs.
> GNOME + KDE != all desktop environments.
>
> Please keep this in mind when making specs.
>
> On Tue, Nov 11, 2008 at 1:41 PM, Zhe Su <james.su at gmail.com> wrote:
> > I'm wondering if it's possible to design a set of standard dbus interface
> > for xdg-utils, then different desktop environments can implement their
> own
> > dbus services to provide identical functionalities through dbus
> interface.
> >
> > Regards
> > James Su
> >
> > On Tue, Nov 11, 2008 at 12:13 PM, 洪任諭 <pcman.tw at gmail.com> wrote:
> >>
> >> Hello the authors/maintainers of xdg-utils,
> >> I'm the lead developer of LXDE. < http://lxde.org/ >
> >> I have some thoughts regarding to some limitations of current xdg-utils.
> >> Here are some proposals to rework it and make it totally extensible.
> >>
> >> Limitations of current implementation:
> >> 1. It only recognize gnome, xfce, and kde and is far from being truely
> >> cross-desktop.
> >> 2. Authors of new desktop environment need to hack xdg-utils to support
> >> their
> >> desktop environments, and hope someday Portland project will include
> >> their patch.
> >> 3. The number of desktop environments is still increasing, and in this
> >> way,
> >> xdg-utils will finally become very complicated and full of dirty hacks.
> >> 4. Even if I only get xfce installed on my distro, xdg-utils still
> >> needs to check all the others.
> >> 5. Portland project is hard to participate. I sent mails to the
> >> mailing list, and they just got ignored.
> >>
> >> Easy and backward-compatible solution for all the preceding problems -
> >> Let desktop environments install their own scripts.
> >>
> >> Implementation Details (Advantages and disadvantages are listed later
> >> in this mail)
> >> Taking xdg-utils for example, it should work like this:
> >>
> >> Looking for scripts in "/usr/share/xdg-utils/xdg-open.d" (or other
> >> places are ok).
> >> Scripts from various desktop environments can be installed there.
> >> 50-gnome
> >> 50-kde
> >> 60-kde3
> >> 50-xfce
> >> 99-generic
> >> The numbers means "priority". The generic one, of course, has the
> >> lowest priority.
> >> This is common practice on UNIX systems.
> >> Then, run the scripts installed by various desktop environments one by
> >> one.
> >> Every script in that dir checks if current desktop session is theirs.
> >> If it is, the script opens the file/url with their own mechanism, and
> >> returns 0.
> >> Otherwise, it returns an error codes.
> >> Once failed, the next script with lower priority will be tried.
> >>
> >> Advantages:
> >> 1. Highly extensible.
> >> 2. Won't break any compatibility with current implementation.
> >> 3. Easy to maintain. (The scripts are all maintained by authors from
> >> respective desktop environments, not you guys from Portland)
> >> It's impossible for Portland developers to maintain hacks for all kinds
> of
> >> desktop environment and constantly fix them for future versions of those
> >> desktop environment. It's quite inefficient and hard to get things
> right.
> >> 4. Don't need to hard code detection for all kinds of desktop
> >> environments in one
> >> very large and complicated xdg-* script.
> >> 5. Only the desktop environments *really* installed on the system are
> >> checked since those scripts are provided by the DEs themselves. So
> you'll
> >> never always try to find gnome or kde, like the current xdg-utils,
> >> even if they are not installed.
> >>
> >> Disadvantages:
> >> 1. The performance is slightly worse. (Since this command won't be
> >> executed continuously in a large loop, it's not a real issue.)
> >> 2. Potential conflicts between scripts installed by various desktops.
> >> (This is not possible if those scripts are well-written)
> >>
> >> For xdg-mime and others, the same method can be used.
> >>
> >> This can solve all of the problems in current implementation.
> >> Any comments? Is it possible to get this new design into Portland
> >> xdg-utils?
> >>
> >> Thank you all in advance.
> >> _______________________________________________
> >> Portland mailing list
> >> Portland at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/portland
> >
> >
> _______________________________________________
> Portland mailing list
> Portland at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/portland
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/portland/attachments/20081111/e4143163/attachment.html