[Portland] xdg_vfs_gnome command line client

[Kevin Krammer]

My take on this, not just replying to Aaron:

On Wednesday 31 May 2006 17:52, Aaron J. Seigo wrote:
> On Wednesday 31 May 2006 09:08, Dan Kegel wrote:
> > On 5/31/06, Jeremy White <jwhite at codeweavers.com> wrote:
> > > Whoa.
> > >
> > > Wait, this all seems like a bad idea to me.
> > >
> > > The concept of xdg-utils, in my mind at least, is that every function
> > > it provides is an abstract desktop environment independent function.
> > >
> > > The whole *point* of xdg-utils is that I don't want to know
> > > the inner details of gnome vfs.

I think the DE specific tools should not be prefixed with xdg and they should 
be maintained at the respective project where they are more likely to stay in 
sync with the framework the operate on.

> i'd take one step further back even and ask: what are the use cases for
> this?
>
> i'm concerned that we're starting to cross that line between "works just
> fine as a CLI tool since it's a fire-n-forget, usually-at-install-anyways
> type thing anyways" to "used heavily from applications, so really ought to
> be in a library". this tool is cool beans for accessing these things from
> the command line (though we already have similar tools; only diff is they
> don't do stdin/out streaming), but honestly:
>
> writing correct source code that constructs command lines (doing this
> safely can be a tricky endeavour at times), fork/exec'ing them and then
> managing them via stdin/stdout fd's (esp when parsing output) is not
> trivial.

True, however feedback from users on our mailinglist, especially users in the 
sense of system administrators, long for options to access our platforms 
through commandline clients in order to be incorporated into scripts.

Most of our (KDE's, very likely applies to other DEs as well) commandline 
tools are really hidden, or poorly documented. Users/admins which are told 
about them are quite enthusiastic about them.

The use case of fork/exec'ing from an otherwise "real" application is just a 
short term solution until real integration through IPC contactable service 
can be achieved, but nevertheless an option that got positive feedback from 
ISVs so far.

> if the use case is "to be used in natively compiled applications" then this
> code should probably be encapsulated into a nice little C library.
> application developers will thank us in the long run and it will likely be
> an easier sell to ISVs.

True, but doesn't invalidate the need for commandline access, but maybe not at 
the same scale.

I would like to ask Norbert if he could check the possibility of contributing 
a GNOME implementation of the DAPI daemon side and maybe put the commandline 
client somewhere GNOME distributors are known to look for addons.
The KDE client could go into KDE extragear.

Cheers,
Kevin

-- 
Kevin Krammer <kevin.krammer at gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtcentre.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/portland/attachments/20060531/a18eb9c2/attachment-0001.pgp