[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: 
>   
Well - there are more differences. For instance the cli-tools which are 
shipped with Gnome-VFS (and used in the xdg-copy script) are pretty 
useless for remote resources:

gnomevfs-copy sftp://user@host/file /tmp/file
Failed to copy ...
Reason: Access denied

No chance to log in. The command line tools are not linked to the 
authentication system of the desktop. The advantage of xdg_vfs_gnome is 
that it has access to the passwords in your desktop session and keyring.
> 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.
>   
Glib, Qt, Java, Python etc have quite convenient functions to handle 
async process creation. And constructing command lines for xdg-vfs  
won't be more complex than for the other xdg-utils.
> 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.
>   
I agree, but there is a difference: xdg-vfs output is (has to be) 
designed to be machine parsable, while the output of ordinary cli-tools 
usually isn't. Good documentation and interface discipline might also 
help...
> 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.
>
>   
I'm a big fan of the "common library infrastructure" approach, but maybe 
it's better to wait for the 'dapi' library...

I tried to make things as easy as possible by doing more steps at once 
(filedialog plus file-get/put). An ordinary application might only need 
those three commands:

$ xdg-vfs openfildlg --instant-get         (File/Open...)
$ xdg-vfs savefiledlg --instant-put        (File/Save as...)
$ xdg-vfs put <filename>                   (File/Save)

cheers,
Norbert