KDE: Breaking the Network Barrier 475
comforteagle writes "In this month's KDE: From the Source, entitled Breaking the Network Barrier George Staikos takes us on a walk-through of KDE's desktop networking protocol handlers in the vein of sftp:// webdav:// and a few really nifty ones I wasn't aware of like info:/ perldoc:/ and tar:/. The entire KDE desktop environment is decked out like this, and as George puts it, 'Microsoft Windows and Mac OS X have a long way to go to catch up with the robust, transparent functionality that KDE has provided since version 2.0.'"
GNOME compatibility? (Score:2, Informative)
Re:What's the difference? (Score:5, Informative)
The KDE feature discussed here is a compatibility layer that allows users to treat a files located elsewhere as if it is on the local disk.
Instead of having to use sftp to download a file from a site, or wget to download a file from the webserver or even evolution to download a file from the mail server, you can just use one common interface for all files reguardless of their storage or access method.
This means a tighter and more consistent user experience.
SO there!
useless protocols? (Score:4, Informative)
Re:Old Unix philosophy (Score:2, Informative)
In fact there is a module for the FUSE system that allows you to use the KDE plugins in the way you suggest.
Wha? (Score:2, Informative)
Like what kind of catching up? Like this?
KDE on Mac OS X [kde.org]
Re:Errr.... security? (Score:3, Informative)
Re:Pretty slick (Score:1, Informative)
> might be the ability to use
> ftp://user@host/blah/blah/blah to WRITE files.
That's the whole point: You can do that in any file box in KDE. For instance, if I wanted to save a copy of this page, I go up to Location -> Save As... then a box comes up and I can type in sftp://foo@host/home/foo/saved-pages/ and save it directly to the remote host.
Additionally, there's a little bookmark icon, so you can bookmark directories/sftp sites/etc. KDE is frighteningly slick when it comes to integration...
Re:MacOS _should_ have these things. (Score:5, Informative)
Re:useless protocols? (Score:4, Informative)
The key advantage of KDE's IOSlaves over protocol handlers in Windows is that in KDE they are transparent and available to every application. This is not the case in Windows or OSX. Gnome-VFS does have this advantage as well, but is nowhere near as extensive.
Re:Pretty slick (Score:4, Informative)
Re:wrong layer (Score:1, Informative)
Package: dog
Description: Enhanced replacement for cat
dog writes the contents of each given file, URL or standard
input to standard output. It currently supports file, http
and raw URLs. It is designed as a compatible, but enhanced
replacement for cat.
Re:Old Unix philosophy (Score:4, Informative)
Because KDE is a cross platform desktop, and devices are too tightly tied to a specific kernel. A Linux device doesn't help a FreeBSD, Solaris or AIX user.
Microsoft has to catch up? (Score:4, Informative)
mk-its: is used in the HTML help system, and ms-help: is used with the MSDN, and there are probably a few others that most people have never heard of.
But like I said, why is it up to MS? Anyone in the open source community could write APPs for Windows to add this kind of functionality if there were a demand for it, so I suspect there's little or no demand for it.
Re:Marketspeak (Score:5, Informative)
The useful thing is for example:
- Writing a webpage in Quanta and uploading it directly to your webserver simply by typing ftp://blahblah in the file save dialog.
- Streaming your movios from an smb share directly to Kaffeine without needing to use smbmount or anything similar. Or stream directly from http or ftp or ssh servers
- Opening an mp3 song from an audio CD. You simply type audiocd:// in the file open dialog and you'll be able to find a virtual mp3 on there. You open it from amaroK and you get an mp3 encoded on the fly. OK, not the most useful usage and not sure if it works, but you get the drift
The point is, if it works from Konqueror, it works from EVERYWHERE in KDE. Automatically.
Re:RTFM- there's no "holdup", it's done it since 1 (Score:4, Informative)
SSH+SCP would be really nice. fish:// on the other hand, is shear brilliance. It uses Perl on the server side to do some things that are not possible with just SSH+SCP. Those are great fallbacks, but fish:// is innovative. But, I'd be happy with just SSH+SCP. As far as I can tell, it doesn't exist in OSX.
This brings me to another annoyance with OSX: It doesn't tell you when it doesn't know about a protocol. I can tell my OS X 10.3 machine to connect to a server. For a URL I type in "bogusprotocol://foo@foo.foo". The Finder tells me, "Connection Failed. No response from the server. Please try again."
WTF? I'd prefer something like, "You moron, you've just typed in a protocol name that doesn't exist." Please don't say, "Sorry, but we couldn't connect to this perfectly valid URL because the host wasn't available."
-Peter
Re:What's the difference? (Score:3, Informative)
The only way to get this across every single application is to include it at the filesystem level. First, the KDE developers aren't kernel hackers, so they probably don't have the expertise to write such an extension.
Second, even if they did, it would probably incite a giant debate in the Linux kernel mailing list when they presented it (like with Reiser4), and the net result would be that it wouldn't be in anyway. So it'd be a bunch of patches and you'd have to use a special kernel to use KDE, which would be awful.
The KDE developers aren't going to rewrite every single application out there to use their functionality (and if they did, people would complain because pine depends on KDE).
In other words, don't choose to use a hodgepodge of programs, and then complain that it works like a hodgepodge of programs.
Re:wrong layer (Score:3, Informative)
I don't see why this has to be at the kernel level - why not just make programs that use kioslave functions instead of open() (or whatever)? Not only that, but some protocols are very slow or don't work with directories well, and wouldn't be sutable to be treated like local folders. Putting this in the kernel is asking for a lot more root (and not just user) exploits. And finally, everything that uses traditional system calls would have to be modified considerably or there will no doubt be many expolits found for them.
Re:But regular people don't think this way (Score:3, Informative)
Re:What a relief. (Score:5, Informative)
Re:useless protocols? (Score:2, Informative)
The real power lies in the webdav, imap, ftp, fish, lan, smb and ldap ioslaves (and their ssl counterparts). These have been present since KDE 3.0 (18 months).
FUSE KIO Gateway (Score:3, Informative)
Not necessarily.....
http://kde.ground.cz/tiki-index.php?page=KIO+Fu
Re:What's the difference? (Score:3, Informative)
But do they have the expertise to write a user-mode NFS server that uses the protocol in question as the back end? There'd still be some platform-dependent crap to do the NFS mount (probably using a port other than 2049, if the platform's NFS client supports that), and there might be some file systems where that doesn't work all that well, but it might work well for many of them.
Unfortunately, NFSv2 and v3 don't have "open" operations, so read/write file systems might be a little painful if the file system protocol is oriented towards copying entire files, as you'd probably want to implement writing by writing to a local copy of the file and writing the file back to the server when it's closed. NFSv4 might help, although that'd help only on OSes with NFSv4 clients mature enough for that purpose (Linux's might be; I think Solaris 10 will have a v4 client which might be; there are v4 clients under development for the BSDs, although I don't know whether they'll end up in OS X at some point).
For access to tarballs, zipballs, and the like, read/write access would be tricky, as you easily can't update individual files in place. If you offer read-only access, a user-mode NFS server would probably work.
Re:What a relief. (Score:1, Informative)
Re:Don't be a hater (Score:5, Informative)
Yes, the Amiga. Just put the file "ftp.device" in DEVS:, mount FTP: and every single application can now use say ftp://ftp.sunet.se/ as if it was a local disk. ftp.device was written in the early 90s but the backend technology was there in 1986...
Re:bleh:// (Score:4, Informative)
...and ctrl-x probably works in a lot of them as well.
And, given that Qt switched in Qt 3 to the closest thing to a standard way of handling the PRIMARY and CLIPBOARD selections in X [freedesktop.org], and that a number of other toolkits, including GTK+, have always done that, it would probably work even between applications using different toolkits in most if not all cases.
I.e., bitching about copy-and-paste in X11 is getting a bit old, at least for complaints about it not working at all, even for text. Perhaps for non-text formats there needs to be a bit more work in the toolkits and applications, but, as I remember, the selections mechanism in the ICCCM does have a mechanism to register data types and to have a recipient of data find out the types in which data in a selection is available, so they can choose the "best" type (e.g., it might be available as rich text or plain text, so that a word processor would fetch the rich-text version but a terminal window would fetch the plain-text version).
Re:Marketspeak (Score:3, Informative)
Basically its an extensible system that allows for any protocol to be used. No one else has that yet.
Re:Marketspeak (Score:3, Informative)
I hope they fix this in Tiger. 10.3 is way better than 10.1 in this respect though.
Re:Marketspeak (Score:2, Informative)
Nonsense. If you don't enter any of the special protocols (for example because you don't know about it) then this is completely hidden and doesn't come in anyone's way. No button, no config option that takes up space or grabs attention.
This is really _no_ usability problem.
OTOH if I choose to use some of the protocols (which I do, most often fish:/) then it's a great boon for me.