Slashdot Mirror
KDE: Breaking the Network Barrier
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.'"
RTFA... This has nothing to do with which application to launch to deal with a specific file. You are thinking of file associations.
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!
I don't get why it is useful to be able to type devices:// or whatever. For some of these protocols the ramifications are totally unclear: if i'd type pop3://myserver/mymailbox would that actually download my messages and effectively erase them from the server? The useful protocols are covered in Win(XP) very well, including the most useful (not mentioned in the article) : webdav over https.
Apple is doing this stuff (e.g. you can mount WebDAV servers), but Apple is doing it right by integrating network resources into the real VFS layer so that all applications can access them. KDE's I/O slaves are not real filesystems and are not accessible by all applications.
Um, you *can* use the browser from within the KDE file dialog. Eg, if you want to open something from your ssh account, you just enter "fish://myself@somesite.com", and it'll open up the remote directory as a directory in the file dialog.
A deep unwavering belief is a sure sign you're missing something...
What was the reason for not implementing these as devices?
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.
Don't blame me, I didn't vote for either of them!
Why does Microsoft need to catch up? Anyone can write an Asynchronous Pluggable Protocol (the handlers for different url monikers). I've written two of them for different applications I've written. It's a great way to tie browsers to HTML not stored on a web server.
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.
Sure, using all these things from the browser interface is stupid, but you're missing the point. Konqueror is not a browser, it's merely a shell which is very nice for viewing webpages. You are not supposed to browse most of these things (nntp, mail etc.) from Konqueror, but you CAN simply because you can embed just about anything into Konqueror.
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.
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
. Penguins Surely Ca
That's great, but please, cite your sources. Googling came up with this site: thebest404pageever
The fact of the matter is that on built in network transparency, KDE has no equal.
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...
My other account has a 3-digit UID.
...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, 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).