iFind, a project of the SENSEable City Lab is an application designed for “Friendspotting”. It uses the ubiquitous Wifi coverage around the MIT campus to allow you to locate where you are pretty much anywhere on campus (minus a few buildings that we don’t have access point information for yet). The application then allows you to share it with whatever friends you want via an encrypted peer to peer link. This means that the information is shared only with who you want it to be shared with, and we as the operators of the iFind service have no information about your location (we can use a couple properties of the MIT network to guess which building you are in, but that’s it).
There are two parts to iFind. The shiny GPL licensed Java client, and the proprietary (sorta) PHP server. I was responsible for about 98% of the server code, and that’s what I’ll focus on, right after a pretty picture….
(yes, they were taken on a Mac. No, it’s not mine, the primary client developer uses it).
The iFind server is a relatively uncomplicated piece of code (around 25 files, and 35KB as a RAR archive), but there are a few interesting aspects. The biggest is that all communication with the server is done via XML. This creates what you could call an XML-RPC (Remote Procedure Call) system, although it isn’t nearly as flexible (aka complex) as other XML-RPC implementations. It is simply a custom defined protocol with a variety of messages that use XML to transfer the data and return the result. The entire protocol documentation is a 71KB Microsoft Word document (it does compress to 14KB as a RAR file though), which we keep somewhat private (it is available on request by sending a message to senseable-ifind [at] mit [dot] edu) to gauge interest. The server code will also be available on request for private use (pending a few agreements on release and such) for research and use at other institutions.
The other interesting aspect is the handling of requests. Once the server does some basic processing, and determines that the request is valid (well-formed XML, and including the expected method field), it passes off the request to an input handler. Input handlers extend a base class using the object oriented nature of PHP, which gives access to a variety of predefined methods and fields, such as an XML class for the output functionality. The advantage to this process is that adding a new method is as simple as adding a properly named file (the method name with no spaces and a .php extension) to the proper folder, and the server will handle requests. Any invalid requests will receive a generic error (either 100 Service Unavailable, or 104 Service Unimplemented) although the behavior is technically undefined (although it has no side-effects, and should not cause any problems or malformed output).
There are probably a few other interesting bits in the server code that I will run across while preparing it for the consumption of others (have to put in some comments and document how to extend it I suppose).
