I’d define a problem worth solving as something that has 3 attributes: It is persistent, in a sense that it reoccurs too many times, that it has an impact on some activity or workflow. That is something worth resolving. Another point is the “factor of annoyance”. Remember the  Microsoft’s Paperclip? High factor of annoyance. One dialog asking for a bit of love in the form of a ok-button? Not that annoying. But keep in mind, that’s all a very subjective rating. So if you find Dialog Boxes more annoying than speaking Paperclips, just change the order accordingly.

The third factor is the most important one: the Time spent working around. The attributes mentioned above may be pointless if it takes no time to work around the issue. If something takes a serious amount of time to be worked around, solved, corrected or understood, it’s time to do something. Recently, GMail and my Mac synced. The result was a Address Book disaster. Time to correct it: 3 hours. That’s a problem.

Anything that’s built to return money should solve a problem or improve something. Anything else? Naaa..That’s my point. What is yours?

There is to date no working revenue model and system for people contributing to open source projects. First of all I want to clearify that from my point of view, it’s not about money creating free software, it’s partially fun, maybe a result of paid work or simply a productive hobby, yet we are living in a world where money counts. So we are happily spending money for everything, while trying to fade out the fact that a lot of stuff we use in our daily lives ( and just be it some free and open source server software we don’t use directly ) is a result of people working for free, out of idealism or whatever.

We need something to show those people our respect. While I’ve been donating like .. 3 times in my live ( each time about 2-5€ ), there are certainly people donating more, and people donating less or not at all. And it depends on how well a project is organised, a good marketing and mostly the project size, it’s highly unlikely that a simple cli-tool meant to be used for just one specific task will be a vital target for money transfers.

So what about a pool, a common adress to receive donations with a ( fair, as far as possible ) system to distribute those amounts among active projects. I haven’t thought about a precise system on how to split those amounts, yet I’m sure that capable people will be able to do so, in a fair manner, which is a cornerstone of this project.

Factors influencing the distribution could take e.g. project activity, team size, download counts etc. into account, although the different uses demand a highly customisable system.

What do you think about it ( Still hoping for comments ) ?

Have fun.

Update

There is a version available for Snow Leopard now, just check out the new post.

After seriously thinking about doing it all by myself, I plugged in Google to get some answers. And there is ruby-ldapserver, hosted at rubyforge. Unfortunately. the project seems pretty dead, nevertheless the Alpha 0.3.1 Version released there works fine, although without SASL support, only simple ( plain bind ) works. 

How to use it? It’s very straightforward. Download the package, see that it’s in your path, and ready to rock. The package includes a few examples, showing off the beauty of the lib and ruby. That is how you implement a fully working LDAP Server ( okay, doing nothing, but works. )

class MyLdapOperations < LDAP::Server::Operation

  def search(basedn, scope, deref, filter)
    puts scope
    puts basedn
    puts deref
    puts filter[1]
  end

  def simple_bind(version,dn,password)
    puts "Auth: #{dn} + #{password}"
    puts version
  end

end
s = LDAP::Server.new(
	:port			=> 1234,
	:nodelay		=> true,
	:listen			=> 10,
#	:ssl_key_file		=> "key.pem",
#	:ssl_cert_file		=> "cert.pem",
#	:ssl_on_connect		=> true,
  peration_class	=> MyLDAPOperations
)
s.run_tcpserver
s.join

You launch it, and it works. Certainly worth giving it a try, and a good piece to start if you want to get involved in the OS community.

Simply , Unpack this file ( tar bz btw ) in your rails app’s root folder and call rake db:superdumper. This will create a file called database.dot in your root folder, containing your database scheme, including associations, in the so-called “dot” format, used by the open-source GraphViz package as input. If you don’t have that package, install it, via ports or apt or whatever applies to your platform. 

In Detail what you have to do is here ( assuming you unpacked the file already.. )
 

rake db:superdumper

This task will automatically dump your scheme and call GraphViz, resulting in a pdf file in the root of your app with the name database.pdf. If it’s not your database schema smiling at you, let me know.

I’m still a bit frustrated that there is nothing like a general file metadata format. While every OS nowadays has its own metadata-supplying filesystem, there doesn’t seem to be a way to exchange that information or reuse it. Neither to publish it online, in a useful manner. I was thinking about a format that enables one to store almost arbitrary information in for a file. Album art, MD5-hashes, Author information, keywords. Anything that helps to categorize a file. Thus, a download would start by clicking on the metadata file, a nice screen would popup showing the file type, the supplied information, giving you the ability to get a quick overview about a file.

This could help to prevent the download of malicious software etc.. And it would help to store files correctly without user interaction. As a teacher of mine noticed correctly, it’s impossible to store and organize files in a useful way using the old-school directory-filename scheme, plus the good old 3-char extension, e.g. avi or txt. Something more sophisticated is needed, and would add a bit more usability to this web.

This is once again just a rough idea, and I would love to hear your comments.

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.

Could a similar system be also built for free blog-to-blog linking? I guess there are many blogs out there dealing with almost the same topics from time to time, and I think it’s a pity that there is no automated way ( i know of ) to link these blogs based on the post contents. While a hard restraint for such a service to work would be that it is free and easy to customise, many bloggers focusing on their readers would embrace such a system. Once again, free and without any commercial background.

Edit: I guess someone’s done some cool work here, the plugin is called Ping Crawl and links to related posts and also pings them. Nice! Edit, 2: Ping Crawl to be quite uncontrollable and since it actually just looks at your tags, it’s not working well. Though text analysis is certainly hard to do, it’s the only way, I’m afraid.

This is another one of my ideas, and I’d be really glad if I could only realise one of them. If you want to help me out, please please please contact me.

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.