After having mastered the fun part of the day, I had a really interesting skype call with a former colleague of mine who is now enrolled at UCL. We spoke about some projects we have been doing, and of course the upcoming ones. And I guess a sideproject of his, 1bucketapp.appspot.com, is really worth mentioning. I don’t know what to do with it, but maybe you can put it to use.

Another, at first sight, useless site is http://750words.com/, a project where everyone is encouraged to write 750 words every day. The texts are not published nor accessible to anyone else but you, so it’s a private diary for everyone who has a need for one. From my personal attempt to use it I can tell that 750 words is a lot.

The last interesting snippet of the day was a collection of tipps for keeping Java code clean and maintainable. Although the text dates back to 2001, it’s still of remarkabel relevance and definitely worth reading.

Let‘s have a look at how characters can be encoded. The most simple approach is to simply put up a table with characters and assign each character a number between 0 and 255. By doing this, you get a character pool with 255 elements and can address each element with 1 byte. This approach is widely still in use, the most popular implementation is by far the ASCII format. These 255 characters did a great job for a long time. By dividing it into a lower and upper part system manufacturers were able to provide e.g. Germany with their beloved special characters, but were as well able to provide language-specific special characters to other nationalities, like French or Spain. By doing this, you gain the ability to use one byte to encode the most important subset of characters, but lose portability. A file created on a german-speaking workstation wouldn‘t be displayed correctly somewhere outside this language zone. That‘s where the concept of codemaps has it‘s origin. Each system was equipped with a codemap, which was nothing more but a table mapping byte-values to chars. 

So there was a need growing, in times of internet and global networking, to encode characters so that they were viewable everywhere, in a consistent manner. Many approaches exist, but the one that is most widely used today and the de-facto standard for encodings is called UTF-8. Fundamentally, it is a multi-byte encoding, that is, each character can be encoded using up to 4 bytes. The exact byte count is determined by the highest order bits, if it‘s 0, only 1 byte is present, if it‘s 1, two bytes and so on. This is a clever approach, since the lower table of ASCII characters is properly UTF-8 encoded, just because the implementation is cool. The lower case table, for your interest, includes all basic numbers, whitespaces, and the alphabet in lower- and uppercase. 

So nowadays, one should definitely use UTF-8. Why? The best thing would be to have everything in UTF-8, e.g. XML-Documents, Text Documents. Most moden languages handle Strings as being UTF-8 by default, only changing the external presentation on request. UTF-8 simplifies development of easily localizable application tremendously, while being simple to manage on the other hand. As exaggerated as it may sound: UTF-8 is indeed the answer to most encoding problems. 

If you want to use it in Java, you are already equipped with what you need. If you want to use C to build a UTF-8-capable application, use the iconv-library, it is open-source and included on every distribution, including Cygwin. Iconv is able to encode almost any format that is there into any other format, and it‘s able to read UTF-8, or work with it to extend the C Standard Library ( which is at the date of this writing not able to do so . 

Hopefully I could give you a brief introduction to what encodings are, and not are, and why UTF-8 should be used. Remind yourself!

I’m already thinking about dropping the Java-project and instead do a client for the giver-protocol in Cocoa. I would be excited to have someone reporting about the actual use of giver! Moritz.

So the question I’m asking is whether it’s that bad that there is no Java support? Yes! Absolutely! At least if you either use programs or build programs depending on it. Of course, most programs just work fine with Java 5, but there are some that just don’t. And so one of the main reasons for Java is obsolete: write once, run everywhere. And while Sun, the company behind Java, is providing Runtime Environments for Windows and Linux, it’s not for Mac. So it’s not Apples fault alone. But careless of who’s fault it is, it just sucks, clearly spoken.

So what is the client’s task? In our example it is to find, that is discover, services and make them accessible to our application. Of course, it uses the same mDNSResponder facilites discussed previously. To mention it again, mDNSResponder is, from our point of view, the single instance taking care about all actions required to either register, discover or browse services. And caused by the way it works ( by “talking” to the other peers on your network ) it can’t provide instant answers to requests made, that’s why asynchronous callbacks are required.

We used that killerapp example, and I’m going to continue with that, though any other name can of course be used.

I assume you already imported the apple package and read about how to install it if you’re unable to compile your class file.

import com.apple.dnssd.*;

Before actually starting to putting it all together, let’s have a look at two interfaces that are important for our work. The one is BrowseListener, which actually defines the callbacks to call when a service is either lost or found.

public void serviceFound(DNSSDService browser,
                         int flags,
                         int ifIndex,
                         java.lang.String serviceName,
                         java.lang.String regType,
                         java.lang.String domain)

public void serviceLost(DNSSDService browser,
                        int flags,
                        int ifIndex,
                        java.lang.String serviceName,
                        java.lang.String regType,
                        java.lang.String domain)

The other interface which is used to provide our application with the data necessary to connect to a discovered service using standard Java Sockets, is ResolveListener. This interface defines only one callback, serviceResolved

public void serviceResolved(DNSSDService resolver,
                            int flags,
                            int ifIndex,
                            java.lang.String fullName,
                            java.lang.String hostName,
                            int port,
                            TXTRecord txtRecord)

which is called whenever Bonjour was apple to resolve a service. Of course, because of the BaseListener interface, operationFailed must be implemented, too. Let’s do something useful now.

First of all, we have to enable Bonjour and tell it what to call in case it finds something. It’s best done by having a Class which handles all the discovery stuff. So whatever your class is, just implement the interface BrowseListener, as the ResolveListener callbacks will be implemented using anonymous classes later. For me, the skeleton looks like this:

public class Discover implements BrowseListener {
	// the constructor.
	public Discover(){

	}

	public void serviceLost(DNSSDService browser, int flags, int ifIndex,
				String serviceName, String regType, String domain) {
	}

	public void serviceFound(DNSSDService browser, int flags, int ifIndex,
				String serviceName, String regType, String domain) {
	}

        public void operationFailed(DNSSDService arg0, int arg1) {
		// this one is required by BaseListener, which is the parent of all other Listener Interfaces.
	}
}

Now I’m going to initialise Bonjour’s browsing capabilities in the constructor. Take care, It throws an exception if something goes wrong. It’s up to you what to do with it.

	public Discover(){
		try {
			browser = DNSSD.browse("_killerapp._tcp", this);
		} catch (DNSSDException e) {
			// do something fancy here.
		}
	}

The method browse requires two arguments, the name of the service you are browsing for, and the callback handler, which is the calling object in that case. Bonjour handles the rest for us, and either one of the methods serviceFound or serviceLost gets called accordingly.

Assuming you are lucky and Bonjour finds a service with that name, serviceFound will be called. To resolve the found service to an IP address and a port, you need to call DNSSD.resolve, a method with the following signature

public static DNSSDService resolve(int flags,
                                   int ifIndex,
                                   java.lang.String serviceName,
                                   java.lang.String regType,
                                   java.lang.String domain,
                                   ResolveListener listener)
                            throws DNSSDException

It’s okay to fill 0 in flags, for further meaning just read the Javadoc. Because our serviceFound method is already called with most of the required arguments, it’s quite easy to implement the resolve process.

DNSSD.resolve(0, ifIndex, serviceName, regType, domain, new ResolveListener(){
				public void serviceResolved(DNSSDService resolver, int flags, int ifIndex,
				String fullname, String hostname, int port, TXTRecord txtRecord){
					InetAddress theAddress;
					try {
						theAddress = InetAddress.getByName(hostname);
					} catch (UnknownHostException e) {
						// ouch..
					}
				}

				public void operationFailed(DNSSDService arg0, int arg1) {
					// ouch, again!
				}
			});

So what’s happening here is that we create an anonymous class to handle the callbacks, which should look familiar if you’ve been doing some AWT stuff. Once the resolve process was successful, the serviceResolved method is called, and we resolve the hostname given there to create an InetAddress object filled with all the information we want to know.

And yes, that’s it. The same applies for the serviceLost method, which has the same signature, and it’s up to you what to do with that address object from now on! Hope this helped you a bit.

Because I’m not in love with one language and used to switching back and forth between several of them, I tend to forget some details about built-in classes etc.. It’s certainly o.k. to have the documentation for such features available somewhere on the web, but I’d love to be able to simply download bundles for a language in a “documentation reader”. Open format ( there are lots of them that would suit this application ), simple to transform anything to it via xsl or something comparable, and it would just work ( even offline ). 

I won’t claim to start a new project here as I’m already quite busy doing the rest, and celebrating new years eve, but if somebody is looking for a challenge, here it is. 

This subject shows another important aspect of usability. Usability shouldn’t stop at the Users place. Developers are users, too. And happy users tend to be more loyal and happy, a goal certainly worth achieving.

Edit: Now the night has finally arrived, and I think the following tasks should be completed before any such project can be forged. 

1. Define an open format for efficiently saving Language Documentation. Keep in mind that language documentation differs in structure depending on what kind of language is documented. Object oriented languages need other formats or present other structures than procedural or functional ones. 
2. Create scripts that convert existing documentation into that new format. XSL is a powerful friend here. No one will ever take care about a cool project without a funky demo.
3. Build clients that are eaasssyy to use for all major platforms. I’m talking about smooth integration ( e.g. a spotlight plugin for OS X ), not some dirty hack.
4. Tell all your programmer friends.

Thats it. But I’m still not ( yet ) interested in doing it by myself, but if anybody wants to do it, don’t bother contacting me. Sleep well.

Edit: found this link, like it.

If you end up in a situation where it’d come in handy to have a pass-by-reference facility, think about the way java is storing objects, and how these objects are then passed-by-value. 

First of all, an object variable contains only a ( typed ) memory address. Thus, comparing e.g. two strings for equality will yield only true if they are in fact the same strings, same applies for all other types. And this is the value. So in fact you pass a ( kind of ) pointer to a function, enabling to manipulate the original object, as the object is not cloned or something else.

Its also common to encapsulate basic types like int into a object just for the sake of manipulating it in some methods.

So let’s break it down to a simple example:

class MInt {
	int x;
}

public void inc(MInt what){
	what.x++;
}

This will result in the int x of a MInt object being indeed incremented. Let’s imagine calling a increase method with a plain integer. This will change just nothing, at least not outside the methods scope.

To use them, you have to install.. nothing on a Mac ( I actually don’t know when they introduced it to be a part of OS X, but anyone not using a 10 year old Mac should be fine ), and Bonjour for Windows for Windows. Install your JRE prior to running the Bonjour installer, as it won’t install the Java Bindings if it doesn’t find a working JRE.

Bonjour is one implementation of Zeroconf. It uses Multicast DNS in combination with DNS Service Discovery to allow for service browsing and discovery. Many Windows-Users may have wondered about the mDNSResponder.exe process running all the time. It’s Bonjour.

So, let’s pretend you’re writing a killer-network-application that wants to notify other instances of it running in the network of its existence. It would have to call it out, which is done quite simply as follows.

First of all you have to do the import stuff, thats self-explaining i guess

import com.apple.dnssd.*;

now let’s call the class thats responsible for announcing the service ServiceAnnouncer. The interface is as follows:

public interface IServiceAnnouncer {
	public void registerService();
	public void unregisterService();
	public boolean isRegistered();
}

It’s quite simple and I intentionally didn’t include any methods for setting the service’ name etc. for simplicity. Now let’s go over to the implementation part.

public class ServiceAnnouncer implements IServiceAnnouncer, RegisterListener {
	private DNSSDRegistration serviceRecord;
	private boolean registered;

	public boolean isRegistered(){
		return registered;
	}

	public void registerService()  {
		try {
			serviceRecord = DNSSD.register(0,0,null,"_killerapp._tcp", null,null,1234,null,this);
		} catch (DNSSDException e) {
			// error handling here
		}
	}

	public void unregisterService(){
		serviceRecord.stop();
                registered = false;
	}

	public void serviceRegistered(DNSSDRegistration registration, int flags,String serviceName, String regType, String domain){
		registered = true;
	}

	public void operationFailed(DNSSDService registration, int error){
		// do error handling here if you want to.
	}
}

The first thing you’ll probably notice is the interface RegisterListener. It contains the callbacks operationFailed and serviceRegistered that are called by the Bonjour library if registering your service either fails or succeeds. Caused by the way Bonjour works this is required.

Let’s have a look at the registerService method. As you can see, it consists basically of calling one static method from the DNSSD class. It’s the method registerService. If you want to have a closer look just look at it’s Javadoc. This method is the core of the whole service-register orgy, and it requires quite a few arguments, although using default values will work for you most of the times. What are these arguments? The method signature looks like this

public static DNSSDRegistration register(int flags,
                                         int ifIndex,
                                         java.lang.String serviceName,
                                         java.lang.String regType,
                                         java.lang.String domain,
                                         java.lang.String host,
                                         int port,
                                         TXTRecord txtRecord,
                                         RegisterListener listener)
                                  throws DNSSDException

Well, the first field is flags, the only flag that is valid there is NO_AUTO_RENAME, which will cause two services with the same name not being renamed automatically ( like “Killerapp 2″ ). Passing 0 is fine if you don’t want this behaviour. The next argument, interface index, is more interesting, as it allows you to specify on what interfaces to announce a service. Passing 0 will register your service an all available interfaces, -1 just for your local machine and other values for the specific device you want. 0 is mostly fine here, too.

Now it comes to the customisable part, serviceName is simply a string containing your applications name followed by some identifier, e.g. “Killerapp running on Killer Computer”. If you pass null, Bonjour will simply use the computers name. Next is the regType field, should be something like “_killer._tcp”. Important is the dot and the underscores. The protocol can, of course, be also udp if you want to.

Domain let’s you choose the domain on which to announce the service, using null is fine here, as well as for the next argument, host. It just specifies the target host-name, but if you pass null, things will work. Next argument is the port on which your application accepts incoming connections.

Bonjour features the ability to have some “payload” associated with your service record, so that not only a name and port are announced, but there is also the possibility for another computer to get a so-called TXTRecord associated with your registered service. This can be quite useful, and if you want to use it, just read further through Apple’s documentation.

The last argument is simply the listener, this is, our class. So passing this will be fine, as we implement the RegisterListener interface. You can use some other object here if you want to, but I think it’s most clean to have it here.

The method returns a service handle of the type DNSSDRegistration, used in the unregisterService to cancel the service announcement.

That’s it for the server part.The client part is explained here!