11 October 2004
Federal Election Looks like we are going to have at least another three years with The Rodent. It also looks like they will have a majority in the senate, which will reduce the senate's effectiveness as a house of review. We might not have John Howard for the entire term though, since he is of retirement age. NineMSN seems to think that Peter Costello is already the leader. It also looks like The Democrats senators up for reelection got completely wiped out, with much of their support going to The Greens. Gnome-VFS Robert Collins wrote an interesting critique on the gnome-vfs API. I don't agree with all the points, and there are some reasons why the API isn't as elegant as it could be. Below are some responses. Initialisation One thing that gnome_vfs_init() does is to call g_thread_init(). Before this function is called, the locking APIs in glib are no-ops. You really want this function called early on if the app is going to use threads, otherwise you will end up with inconsistencies (eg. a lock() call might be a no-op, but the unlock() call might not be if g_thread_init() is called in between). The other issue is that gnome_vfs_init() can fail. If it is called automatically, then any function that might invoke the initialisation routine now has a new failure mode. I don't know whether this is a real problem or not though. Calling Style - Inconsistent Ordering One big difference between the out parameters in gnome_vfs_open() and gnome_vfs_read() is that the first function is essentially a constructor for a file handle, while the second is a method for a file handle that fills in a provided buffer. I'll agree that the calling conventions are not as nice as they could be though. If they were being designed today, I suspect that they would look more like this: GnomeVFSHandle *gnome_vfs_open (const gchar *text_uri, GnomeVFSOpenMode open_mode, GError **error); GnomeVFSFileSize gnome_vfs_read (GnomeVFSHandle *handle, gpointer buffer, GnomeVFSFileSize bytes, GError **error); Unfortunately, the GError API was not developped til the 2.0 series, while these parts of the gnome-vfs API persist from the 1.x days. Calling Style - Inconsistent Method Naming I agree that the gnome_vfs_truncate() function name is inconsistent. My guess as to why they chose gnome_vfs_truncate and gnome_vfs_truncate_handle() was to match the underlying truncate() and ftruncate() C library calls. This was probably a case of balancing consistent APIs with ease of transition from libc APIs to gnome-vfs APIs. Returning data to pointers I agree that the existing calling convention is not as nice as it could be. As I said earlier, it would probably have been designed to use GError if it was being developed today. The GError API has a number of benefits over errno style ones, including: Automatically threadsafe. The place where the error is reported is on the stack. A global variable is a problem for multi threaded apps on systems without Linux 2.6 style thread local storage (you need to do tricks like making errno into a function…