J5’s Blog

I went to see the Sheryl Crow/John Mayer concert last night at the Tweeter Center in Mansfield. I love how they both kept saying hello to Boston even though we were in Mansfield. I wonder if smaller towns ever feel slighted because of this phenomenon. In reality, I’m sure they love the tax revenue and despise the traffic.

Great company, great music and it didn’t even rain all that much. Just a bit of drizzle here and there. Our seats were great. We were dead center stage three rows up from where the uncovered section started. I would have gotten even better seats had I know about the concert earlier.

One of my favorite parts of the evening was during one of Sheryl Crow’s war protest songs (I think it was Redemption). On the screens in the background they flashed some pretty powerful quotes. One of them was from an historical figure I idolize - Abraham Lincoln. It went “The best way to destroy an enemy is to make him a friend”. Sounds just about right.

I discussed this project with a few people and GUADEC and finally have gotten around to actually starting it. Below is a rough outline of what could become a series of books written about D-Bus and related technologies.

This first book will concentrate on the D-Bus concepts , trying to introduce the model, terminology and best practices with an eye towards practical knowledge as one of the biggest barriers to developing with D-Bus is understanding the base concepts. Because of this the book will focus solely on the 1.0 D-Bus core API with a little place at the end reserved for various authors to briefly introduce various binding API’s. The hope is that other books would be forthcoming which would go into depth on the bindings subject.

This will be my first book and I haven’t decided on anything other than I am going to write it. I’ll leave all the nitty gritty details (such as how we are going to publish it) until after I have some content to show.

Please read over the outline and give suggestions on topic you would like to see covered by the book.

Working Title: Driving D-Bus

Forward
In the beginning (History of D-Bus)
Basic Concepts
	Object Oriented Design
	Bus'
		System
		Session
		Arbitrary
			Transports
		Bus API Overview
	Bus Names
        Objects
	Interfaces
	Messages
		Method Calls
		Method Returns
		Error Returns
		Signals
	Filters
	Threading
	The Life-cycle of a Message
		Async vs Sync (pending calls)
	Introspection

Creating your first app to talk to the bus
	List Names

Creating your first provider/consumer pair
	Who's the server and who's the client

Creating a more complex app for listening to HAL events

Bypassing the bus - creating your own server

Spot the mistakes
	Methods of debugging the bus
	examples of apps with obvious flaws that D-Bus writers commonly run into

Reaching Higher Ground - An overview of select bindings
	GLib
	Python
	Qt4

Refrence
Glossary
Extended Reading

I’m sitting in my living room listening to a new album I picked up last night. If you like John Mayer, Jason Marz or other pop/jazz acts you will really like this Boston local’s music. I saw his duo act last Wednesday at Starbucks in Davis Square . Starbucks was holding one of the many NEMO Music Maker showcases where he was one of the acts. He played with a full band at The Lizard Loung in Porter Square last night which was a blast. Hopefully I will have time to see him play again at the NEMO Festival at the end of the month.

I am proud to announce the release of D-Bus 0.92, the “Hanging By A Thread” release. This release has multiple improvements in the threading subsystem including proper thread locking in pending calls and the move from enforcing early thread initialization to the more flexible initialize before the second thread is started semantics. There are also a large number of bug fixes that went into this release.

As of now there are only a few more blocker bugs and TODO items before we can reach the all important 1.0 milestone. In particular the auditing of the todo and fixme comments in the code is one of the more important parts that can hold us back. It would be of great help if we could get some eyes on these sections and see if we can get some patches or just punt ones that aren’t all that important.

So have fun, download it, bang on it and join us on #dbus on freenode.net to how you can help to accelerate the final release and get your name in the 1.0 credits.

As always:

http://dbus.freedesktop.org/releases/dbus-0.92.tar.gz

Many smart people have been commenting that GNOME apps should come out of the box web ready. I think I lamented once on this blog about the fact that we as FOSS developers have access to tons of great server software yet we do little to integrate with them. Why is that? While the technology to connect software running on other servers is there, beyond the standard, e-mail, web browser and rss reader we really haven’t ventured far. We certainly haven’t ventured far enough in terms of creating personal Internet servers that run from your standard GNOME app.

What we have done in the past few years is create a rich interconnected desktop and within the past year personal servers which work over intranets have been added to a few programs. I attribute this to technologies such as D-Bus, HAL and Avahi. When Havoc wrote his manifesto about hardware abstraction it inspired David Zeuthen to write HAL. HAL enabled all sorts of application integration with the hardware on the system yet at its core it simply gathered information from the system and presented it in an easy to grok form that desktop developers found easy to use. Before HAL the same things could be done by grokking sysfs and listening to hotplug events but few apps would do so and even if they did they did it in very limited ways. Avahi is another example of a technology that has turned developers minds into creating apps that are well integrated. Because of Avahi I can discover services on an intranet and a number of GNOME apps can take advantage of it. It is kind of nice to be able to put my laptop on a network and be able to browse my friends music collection.

So what do these technologies have in common? They presented consistent interfaces in a way which GNOME developers were comfortable using. So how do we make GNOME developers comfortable with adding personal services to their applications? One crazy idea is to use an interface in which many GNOME developers are already comfortable using. That interface is D-Bus along with a yet to be created D-Bus to XML-RPC/SOAP gateway which would mostly be transparent. Imagine while creating D-Bus interfaces for the local host to utilize a developer could simply tell the gateway to export a couple of methods over the Internet. In this scenario a developer would be freed from having to figure out yet another technology (assuming they already are using D-Bus) and could concentrate on scope and security issues. The gateway could also be used on the client side to talk with existing web services.

D-Bus really isn’t a ground breaking technology here. It is simply a technology that many people know how to use and provides good integration into the GLib mainloop. Any number of libraries can be written to enable webservices within GNOME. No matter how we do it hopefully someone will step to the plate and enable app developers to start thinking of how they will web enable their apps. It should be a fun ride.

Well after trying to figure out the hoops I needed to jump through to prove I owned martianrock.com (my address had changed, my service provider who’s e-mail I had listed had gone away and I couldn’t find my NetworkSolutions password which was being mailed to the e-mail address I had listed) I finally decided to pick up the phone. Wouldn’t you know it only took a few seconds to verify with a live tech support who I was and to get everything in working order. The do it yourself process still has a long way to go in replacing over the phone, live tech support. I must say the NetworkSolutions guy I talked to was very helpful and curtious even if he kept trying to sell me on their hosting services.

For those who don’t know what martianrock.com is, it was my old domain that housed my consulting company’s web site and then later my blog. I still have the DBA for Martian Rock Interactive. Right now j5live.com and martianrock.com both point to the same place. I kept the old domain for identity reasons. I think google still brings it up on searches and well some people still know my e-mail address (though it has been down for months now). In any case it is a part of me and my history that I would be hard pressed to part with.

GNOME 2.16.0 Beta 2
===================
Yes it is here. The second Beta release which leading up to imminent release of 2.16.0 has hit the shelves and is going fast. Come and get yours before all the bugs are filed and you are left out in the cold. Wouldn’t your mom be proud if you told her “I participated!”. Speaking of which, I would like to dedicate this release to the person who made it possible for me to do releases. It is her birthday. Happy Birthday Mom!

We are pleased to announce the release of GNOME 2.16.0 Beta 2 (2.15.91). This is one of the last releases in the 2.15 development series and represents a release that is now API/ABI, feature, string and UI frozen. This means that we’re pretty close to the final 2.16.0 release. The GNOME contributors are now busy fixing the most important bugs that are still out there, localizing the whole desktop or updating our documentation.

You can still make a difference and contribute to the best GNOME release ever! Do you see all the 2.15.91 tarballs? Go download them. Go compile them. Go test them. And go hack on them, document them, translate them, fix them.

The release notes that describe the changes between 2.15.90 and 2.15.91 are available. Go read them to learn all the changes in this release:

platform - http://ftp.gnome.org/pub/gnome/platform/2.15/2.15.91/NEWS
desktop -http://ftp.gnome.org/pub/gnome/desktop/2.15/2.15.91/NEWS
admin - http://ftp.gnome.org/pub/gnome/admin/2.15/2.15.91/NEWS
bindings -http://ftp.gnome.org/pub/gnome/bindings/2.15/2.15.91/NEWS

Basic stats:

admin 2.15.91 statistics:
tar.gz: 880K total
tar.bz2: 708K total

bindings 2.15.91 statistics:
tar.gz: 28M total
tar.bz2: 19M total

desktop 2.15.91 statistics:
tar.gz: 162M total
tar.bz2: 118M total

platform 2.15.91 statistics:
tar.gz: 53M total
tar.bz2: 37M total

The GNOME 2.15.91 release is available here:

platform sources - http://ftp.gnome.org/pub/GNOME/platform/2.15/2.15.91/
desktop sources - http://ftp.gnome.org/pub/GNOME/desktop/2.15/2.15.91/
admin sources - http://ftp.gnome.org/pub/GNOME/admin/2.15/2.15.91/
bindings sources - http://ftp.gnome.org/pub/GNOME/bindings/2.15/2.15.91/

To compile it, you can use GARNOME (will be released soon), or the jhbuild modulesets available at:

http://ftp.gnome.org/pub/GNOME/teams/releng/2.15.91/

If you already have jhbuild installed and bootstrapped you can help out by copying this file
to ~/.jhbuildrc and issuing this command:

jhbuild -m http://ftp.gnome.org/pub/GNOME/teams/releng/2.15.91/gnome-2.15.91.modules build meta-gnome-desktop

Remeber to edit the .jhbuildrc file to point to the correct directories for installation.

Further instructions can be found at the smoketesting wiki page

I put a 2.15.91 moduleset up at http://download.gnome.org/teams/releng/2.15.91

It may take awhile for the ftp servers to sync. Get it, test it and tell me if there is any issues. This is the first release with gtk-sharp in the binding set and tomboy in Desktop. Let me know if the modules need to be cleaned up a bit more.

Included with the moduleset are two patches that need to go in jhbuild’s patch directory. There is also a sample jhbuildrc file for your convenience.

A bit of a warning to those who use D-Bus and GNOME-VFS in the same app. Since GNOME-VFS uses threads and has now switched to using D-Bus it is prudent to initalize threading as early as possible to avoid D-Bus threading being intialized after a connection is established. If such a thing should happen asserts would cause the application to crash as the already created connection would have a dummy mutex while the global mutex lock would be a glib mutex. Initalizing threading early using dbus_g_threads_init() (or dbus.glib.threads_init() in python) avoids this issue by making sure the global mutex is set before any connection is created no matter what your libraries do.