[Portland] xdg_vfs_gnome command line client

[nf2]

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.
>>>       
>> Agreed.  nf2, would it make sense to merge the two to have a common
>> commandline interface and accept identical input?  i.e. to make them both
>> implement a common "xdg-vfs" command syntax and semantics?  We want to hide
>> the differences between desktops, not accentuate them.
>>     
>
> 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.
>
> the trend has been to take applications like apt and rpm that were for years 
> used in such ways and build libraries for them for such uses. this is being 
> done not because there is a library fetish out there, but because -it works 
> better-. in cases where this hasn't happened yet, such as in the case of 
> cdrecord, it causes a lot of headaches for developers (in the case of 
> cdrecord its because it's output keeps changing from version to version). we 
> should try and avoid recreating past mistakes.
>   
Just a thought: "dbus out-of-process components"

As far as i know, dbus can not only be used through a session daemon but 
also point to point via a socket. If dbus could be extended to 
communicate through a pair of pipes (stdin and stdout of a child 
process) we could build a simple out-of-process component system.

executables like rpm, cdrecord, xdg-vfs could be started with a 
"--dbus-component" option and all the communication would be handled by 
the standardized dbus message protocol through the stdin/stdout pipes.

Perhaps such a simple component model could serve very well for all kind 
of tasks (file, print dialogs, vfs-client,...)

regards,
Norbert