[Portland] why not a CLI?

[Ian Murdock]

Hi,

I've gone back through the archives and read up on the current dapi
work, and my first question (which I'm surprised no one else has
asked) is: Why is dapi not just a bunch of scripts that provide a
desktop-independent CLI to the various desktop-dependent mechanisms?
With the current library/daemon approach, we're opening
ourselves up to all kinds of potential ABI/wire protocol compatibility
issues, and indeed the various discussions over the past few
weeks have centered primarily around the need to be very careful here.

Looking through PortlandIntegrationTasks, I see very few things that
couldn't be implemented very simply using a shell script. For example,
disabling the screen saver could be a script called
dapi-disable-screensaver that takes no arguments, with
a dapi-enable-screensaver that reenables
it. No ABI or wire protocol compatibility issues here.

Granted, there are some tasks which probably aren't well suited for
the CLI approach (a common file selection interface across
Gtk/Qt/GNOME/KDE comes to mind here), but we should be picking the low
hanging fruit first, and there seems to be plenty of that.

Last (but certainly not least), I seem to remember from the Portland
meeting that the ISVs in the room actually proposed the CLI approach.
Why aren't we taking that feedback into account here?

In short, it seems to me like we're using a sledgehammer to drive the
nail here.

-ian
-- 
Ian Murdock
317-863-2590
http://ianmurdock.com/

"Don't look back--something might be gaining on you." --Satchel Paige