Advogato blog for tjansen

1 Oct 2003

Wed, 1 Oct 2003 10:00:08 GMT

GObject for language-independent APIs
mikehearn proposed using GObject as a way to share libraries between different languages and platforms. I think there are two problems with GObjects that are much bigger than those that he mentioned:

GObject does not allow to browse the methods of a class at runtime and invoke them (what Java calls introspection and MS Automation). This is needed for making scripting/dynamic languages first-class citizens, as it is not realistic to expect that wrappers for a large set of libraries and languages can be kept up to date. Any viable contender for cross-language APIs needs to offer introspection
GList, gchar strings and friends are a problem, because the performance cost of converting them to the high-level platform's types are high. gchar strings would need to be UTF8-en/decoded for every call if the platform uses unicode. GLists would have to be converted into the platform's native list representation, which is a o(n) operation. The only clean solution is that every type except numbers must be represented by a GObject as well.

26 Mar 2003

Wed, 26 Mar 2003 09:58:24 GMT

BitTorrent
I don't understand the fuss about BitTorrent and similar systems. In the end I pay with my own bandwidth. For each file that I download I will have to upload at least the same amount of data, otherwise the system can't work. And here comes the problem: for me, as a regular dial-up or DSL user, bandwidth is much more expensive than for someone who hosts the file on a server. At T-Online, Germany's largest provider, I pay 15,90 EUR (ca. $15) per GB. On the other hand, when I co-locate a server, I don't pay more than 5 EUR per Gigabyte (at fileburst.com the rate is <$1/GB). And routing the traffic through dial-up, cable and DSL connections instead of dedicated servers is complete nonsense, technically seen, more expensive for the network infrastructure as a whole and almost always slower. The only reason why people do this is because a) they have flat rates and b) there is no easy way for micropayments. I think sites that require the user to pay for bandwidth are a much better way to solve the problems for content creators. Flat rates will soon be a thing of the past when things like BitTorrent get more popular, and even if the processing overhead for micropayments is %80 the bandwidth from a dedicated host is still cheaper than the bandwidth cost for many dial-up/DSL users.

17 Nov 2002

Sun, 17 Nov 2002 23:59:04 GMT

4 Nov 2002

Mon, 4 Nov 2002 19:35:52 GMT

File sharing

One of the things that I would like to have in KDE 3.2 is better and easier file sharing. Right now, KDE's file sharing mechanism is pretty limited. Basically it allows you to export a directory via NFS and SMB, but both protocols (or at least their current implementations) are not ideal for a desktop. Nor is LISA, KDE's current network browsing mechanism.

My requirements for desktop file sharing are:

sharing a directory must not change any permission rules on the server (unless the user is authorized to make a directory available for everyone)
in an unmanaged network, sharing a directory must not require any configuration beside marking the directory as shared
it must be possible to browse shared directories on the network (with all available information)
it must be possible to attach a description or a descriptive name to a shared directory
it must be possible to access the shared directory from every computer, even in an unmanaged network, with a username+password account that is valid on the server
in a managed network it must be possible to access all directories without additional login
the browsing mechanism must scale in very large networks
it should be possible to establish a 'trust relationship' between two computers (for example two computers in a home network), so the user does not have to log in every time
the file transmission should be encrypted, at least optionally
it should use an existing protocol and server, if possible

I think that I have found a very good and simple solution for this: fish. It fulfills every single requirement except the browsing ones. For browsing, I plan to use a very simple (KDE-independent) daemon that keeps SLP registrations open. It can run with user permissions, but should be running all the time. This, the required slp daemon and the performance are the disadvantages of this solution.

SOAP+web services

My webservices implementation reached a dead point at the weekend. This usually happens when I am stuck in boring and unpleasant work. The WSDL implementation is the culprit, implementing this is much uglier that I expected. I guess I will spend the next few days on the file sharing stuff and syncing the GStreamer bindings with the new release...

2 Nov 2002

Sat, 2 Nov 2002 16:39:59 GMT

Wow, almost 6 months since my last entry. I produced a lot of code since then and have even more stuff in the pipeline. I'll try to summarize what I was doing in the last months...

KDE Desktop Sharing

Well, it's done - at least for KDE 3.1. All user-visible references to the old name 'krfb' have been removed. Now the official name is 'desktop sharing'. I never liked the habit of giving strange names to applications anyway. Who knows what a 'Noatun' or a 'Nautilus' is? I also added a few new features: if you configure it to accept connections without prior invitation, it will announce its presence via SLP. That allows an administrator to search for users on the network without knowing the name of their computer. I also enhanced the protocol to transmit the position of the cursor. This can reduce the traffic a little bit, and makes it possible to have a larger or more conspicuous cursor on the client.

So far the application is optimized for a single use case: an inexperienced user wants to invite a friend or administrator to help her. Unfortunately this is not, what most of the people, who downloaded the software or tested the KDE betas, wanted. Most of them seem to have several computers and want to control them from a single machine. Desktop Sharing is not a good solution for this, and never will be, because the performance is quite bad and the user must be logged in all the time. Using the regular VNC server is a better idea, but most people seem to have problems configuring it. See below for a X11-based solution for that problem. Another use case that is not optimized yet is an administrator who wants to connect directly to a group of workstations. Because of VNC's very limited authentication mechanisms the only way to authenticate is against a single master password that is stored locally. This is, well, sub-optimal if you have a few dozens or even hundreds of workstations. I plan to solve this problems by extending the protocol with Kerberos support.

Remote Desktop Connection (krdc)

Yes, I finally managed to produce a VNC client, and it's in KDE 3.1. I took the TightVNC unix client and rewrote it to run in two threads, controlled by a Qt GUI thread. I also added a few GUI goodies, like a much nicer fullscreen mode and a 'scaled' mode that scales the content to fit the window. For Desktop Sharing it supports user browsing via SLP and the 'soft cursor' extension. Planned features for 3.2 are Kerberos authentication for Desktop Sharing, and possibly a ssh/X11 mode. Instead of using VNC, it should log in using ssh into a remote computer and start a regular X11 session. krdc will then run an embedded xnest locally. It will look like VNC and be as easy to use, but with the more bandwidth-friendly gzipped-X11. This solution has a lot of advantages, you only need to have ssh running on the remote computer and you have the full ssh authentication and encryption options. It should be the ideal solution for the "user with several workstations" use case (unless the user uses a non-KDE environment on the client).

GStreamer

I had a few weeks of vacation in august and wrote KDE/Qt wrappers for GStreamer. I am quite impressed by GStreamer's architecture and I think it will be a worthy contender for KDE 4.0's multimedia framework. I decided not to work on GStreamer projects in the next few month though. I have a lot of other things that I want to do, and Gst still has a number of rough spots that I experienced while writing a few examples for the binding. Instead of losing time while working around them, it's better to wait a little bit for GStreamer to mature...

Code documentation

I have always been a friend of JavaDocs, kdoc and similar API documentation systems. The quality of documentation is an important point for me when I decide whether I use a system or not. For example, Python is a nice programming language, but there is no good API documentation available. The official library reference is just a document, which makes it quite useless for me. There is no standard for Python API documentation (so every library is documented in a different way), it is not cross-linked with other documentation, and a document makes it too hard to find a function or class.

KDE's API documentation is pretty mediocre. Some classes are really well-documented, but others are incomplete or not documented at all. So I started adding missing documentation. So far I am through with the kdecore and dcop packages, every single class, function and argument is documented now. It is not as good as I would like, for example it needs more examples, but it is a beginning. Right now I am working on kio, and I hope to finish kfile and kdeui for 3.2 as well. Documenting classes is like playing Tetris, really adicitive, you should try it :)

SOAP+web services

During the hard feature freeze for KDE 3.1 I started writing a WebServices package. Originally I only wanted to implement sending SOAP messages, but then the new DCOPRef syntax inspired me and I wanted RPC as well. It got bigger and bigger, now I have a XML-Pull-Parser API, a WSDL implementation and soon Soap RPC. I hope to release it when the feature freeze is over.

24 May 2002

Fri, 24 May 2002 09:10:29 GMT

SOAP

A few points on the SOAP discussion:

SOAP itself does not mandate transmission over HTTP. You could, for example, use BEEP as a transport.
SOAP over HTTP was definitely designed to get through firewalls and HTTP proxies. This is the reason why people use HTTP and not a superior transport like BEEP (that would allow communication from the server to the client without pulling). If it did not use HTTP all those web services would not work for many problems, it would require a huge change in the infrastructure. Basically everybody who can access the web only over a www proxy could not use those web services.
If your problem with SOAP is that you can not prevent a user/client from using it, read my last entry - you can not effectively limit the user's communication anyway.
if your problem with SOAP is tunneling the firewall on the server side: you dont want SOAP to run on port 80, use another port. If you dont want to use HTTP, you are free to use another protocol. You will lose a lot of users/customers, of course, because many of them wil not be able to use it.
I also don't buy the 'build an abstraction layer around the interface' argument. Basically SOAP is the abstraction layer. If you write one yourself you write more new and unproven code and introduce more potential security leaks. And, of course, you will lose a lot of time that you can also spend on making your code more secure.
If your problem with SOAP is that it makes it too easy for server developers to shoot themselves in the foot: if you really take a COM object and make it available via SOAP without a security audit then, well, it is your fault. But the technology is not bad only because it allows stupid people to do stupid things. If that was true Unix would be the worst of all operating systems...

22 May 2002

Wed, 22 May 2002 10:58:29 GMT

SOAP and security
I cannot understand the 'SOAP and Security' discussion. Of course you can use SOAP with HTTP as transport to get through a firewall and it's stupid to make such a fuss about it. When you allow a system behind a firewall to communicate with arbitrary systems outside of the protected network, you can not limit its communication. SOAP just makes it easier for the average programmer to do this, but you can achieve the same thing with REST, emails or even DNS. A firewall may make it a little bit more inconvenient for a user to connect to the outside, for example you can prevent them from using Real Audio apps by blocking the appropriate ports. But if they really want to, they can - theoretically - stream the data over an DNS tunnel.
Beside monitoring, the only good reasons for a firewall are to

block incoming connections to some or maybe even all ports, in order to prevent access to systems and/or protocols that the admin does not want to expose (e.g. X11, NFS, printers).
in the case of application firewalls: make sure that no currupted data is sent, to exploit things like buffer overflows, and maybe to limit the capabilities of the protocol. For example an application firewall could prevent POST requests in HTML. This could be used to 'cripple' the server and turn off unused functionality that may be exploited otherwise. It's just another form of risc reduction.
Block outgoing connections to ports, in order make it inconvenient for users in the secure net to use certain apps. This is more about telling users what they are allowed than actually preventing it, unless you block all ports.

This is what you can expect from a firewall. What you can not expect is to prevent a protocol, that has been designed for transmitting documents and form data, from being used for other purposes.

SOAP itself is not dangerous, and the code that handles SOAP requests is not more dangerous than any CGI script. The input and output just have a more restricted form which should make it rather more secure.

krfb/krdc: After the failure of the windows vncviewer port attempt I tried to port the UNIX vncviewer, with much more success. The thing, now called 'KDE Remote Desktop Connection' or krdc, is not very far from being complete. I am currently working on the fullscreen mode...

6 Apr 2002

Sat, 6 Apr 2002 23:04:38 GMT

krfb: Started porting the windows vncviewer, but then decided against it. While it would certainly be possible and less work than the other alternatives it is more work than I had hoped. Porting with the full feature set would probably cost me a whole month (working in my spare time). So I scrapped it, for now, and will spend the rest of the weekend working on the krfb server.

5 Apr 2002

Fri, 5 Apr 2002 16:01:37 GMT

krfb: A few days ago krfb has been moved into the kdenetwork package, so chances are good that it will appear in KDE 3.1. This makes a KDE client even more neccessary, but unfortunately I haven't heard anything from the QT-VNC guy. Right now I am considering to port the windows vncviewer directly to KDE. It doesn't look very difficult and should be easier than taking keystone and rewriting the vncviewer code to fit. But even if I would finish this I know that I will spend endless time maintaining this, which would hurt the other things that I have planed to do... I will see what I can get done this weekend..

11 Mar 2002

Mon, 11 Mar 2002 23:40:53 GMT

A few weeks ago, on the same evening I wanted to start improving keystone somebody appeared on kde-devel and said that he implemented a QT-based VNC client and wants to port it to KDE. So I gave up the keystone idea, even though I haven't seen the new client yet and I am not sure whether it will actually see the light of day.

Progress on krfb 0.7 is ok, the KControl module is working, the kded module (kinetd) looks good (but wasnt actually tested). Now all that I need is the invitation feature and make sure that everything works. I hope to get 0.7 out this month. After 0.7 a loose code freeze will start, and I only plan to do bugfixes, maybe add some minor features and, of course, documentation and i18n stuff.