klik:// pseudo protocol, KDE integration, MIME Types
Despite unclear security measures with it (this system makes it probably as easy for Linux newbies to get a trojan as it is already for Windows noobs), I pretty much like the idea of one-click installations and fully stand-alone and encapsulated program packages.
I'd however like to point out (nitpicking of course) that your use of that "klik://" pseudo protocol is very much against all standards. I suspect it is because your primary or only target are KDE users, and it is to hook into there much easier using new protocol-prefixes. To be standards compliant (WWW, XML, XHTML especially) you should however only use "x-klik://" to explicitely mark it as experimental and non-standard, so it won't yield problems.
A better alternative was to abandon that redundand prefix, even if it looks so nice at a first glance. MIME Types are more appropriate for that task anyhow, and would allow to hook the klik system into nearly any Web browser and outside of the KDE landscape (which pretty much seems to be the only system suffering from too many of those pseudo protocol prefixes).
For example "application/x-klik" would be an easy way to go. Additionally that klik server could send it with a header of "Content-Type: application/x-klik; depends=glibc2.3,mplayer; arch=i686" or so. I think this is superiour to any pseudo protocol prefix klik:// which in fact is only an alias to HTTP. And I don't think a mime type is any harder to chain into KDE than such an URI prefix.
Else, a great idea.
Re: klik:// pseudo protocol, KDE integration, MIME Types
Quote:
Originally Posted by tmp000
Despite unclear security measures with it (this system makes it probably as easy for Linux newbies to get a trojan as it is already for Windows noobs), I pretty much like the idea of one-click installations and fully stand-alone and encapsulated program packages.
I'd however like to point out (nitpicking of course) that your use of that "klik://" pseudo protocol is very much against all standards. I suspect it is because your primary or only target are KDE users, and it is to hook into there much easier using new protocol-prefixes. To be standards compliant (WWW, XML, XHTML especially) you should however only use "x-klik://" to explicitely mark it as experimental and non-standard, so it won't yield problems.
A better alternative was to abandon that redundand prefix, even if it looks so nice at a first glance. MIME Types are more appropriate for that task anyhow, and would allow to hook the klik system into nearly any Web browser and outside of the KDE landscape (which pretty much seems to be the only system suffering from too many of those pseudo protocol prefixes).
For example "application/x-klik" would be an easy way to go. Additionally that klik server could send it with a header of "Content-Type: application/x-klik; depends=glibc2.3,mplayer; arch=i686" or so. I think this is superiour to any pseudo protocol prefix klik:// which in fact is only an alias to HTTP. And I don't think a mime type is any harder to chain into KDE than such an URI prefix.
Else, a great idea.
I'm afraid I must post out that in fact the reason for the pseudo protocol is because it is not simply an alias for http but in fact signifies that the hostname/programname should be given to the klik program as an argument, the klik program then gets and runs the recipe. Perhaps instead a mime-handler could be added for recipes, but it doesn't leave the user with as simple a scheme to remember and it doesn't mean you have a command line klik app that can be used identically. Also it is worth noting klik support is implemented/imminent for elinks and firefox.
Not argue about whether or not it is the correct way to do it (standards) just want to draw your attention to a few things.
Re: klik:// pseudo protocol, KDE integration, MIME Types
Hi tmp000,
thanks for your input which we appreciate.
Quote:
Originally Posted by tmp000
this system makes it probably as easy for Linux newbies to get a trojan as it is already for Windows noobs
It doesn't, exactly for the reason that we do not use MIME Types. If we were using MIME Types, then anyone could set up a server to send the neccessary MIME headers, and in turn anyone's recipes would be run by the klik client. But since we are not using MIME Types, the klik client does not run anything except recipes from the official klik server. Please note that klik URLs do not contain a hostname, so they are not only easier to remember, but also it's impossible to trick the user with modified klik links. In fact, it's just a matter of trusting the klik server or of not doing so (as with any server you are downloading from).
In summary, "it's not a bug, it's a feature" ;-)
Greetings,
probono
Re: klik:// pseudo protocol, KDE integration, MIME Types
Quote:
Originally Posted by probono
Hi tmp000,
thanks for your input which we appreciate.
Quote:
Originally Posted by tmp000
this system makes it probably as easy for Linux newbies to get a trojan as it is already for Windows noobs
It doesn't, exactly for the reason that we do
not use MIME Types. If we were using MIME Types, then anyone could set up a server to send the neccessary MIME headers, and in turn anyone's recipes would be run by the klik client. But since we are not using MIME Types, the klik client does not run anything except recipes from the official klik server. Please note that klik URLs do not contain a hostname, so they are not only easier to remember, but also it's impossible to trick the user with modified klik links. In fact, it's just a matter of trusting the klik server or of not doing so (as with any server you are downloading from).
In summary, "it's not a bug, it's a feature" ;-)
Greetings,
probono
Very well thought out, the only thing that could screw this up is users downloading a "unoffical" version.
