<xml.lt>

First post using Firefox 3. I hope we'll set a proper download record today :) The demand must have been so high that Mozilla servers seem to be down once in a while.

For those who do not have (or know!) it, get Firefox!

kbh.dk, a local social network for Copenhagen which I was working on, was officially launched on monday, with talks, demonstrations, free beers and snacks :)

Check out the events section which I was mostly responsible for, including third-party event feed import, simple recommendation system suggesting relevant events, and SMS backend responding with events that take place close to a specified location.

As the W3C best practice goes, cool URIs don't change. While I was aware of it, I stumbled upon it in a real-life situation and was convinced that stable URIs are not only abstract concept, but can also be an issue in development.

In the DIY Framework resources function as real objects connected to domain objects they stand for, and have explicit URIs. They are also stored in a database where URI becomes, logically enough, a primary key. The URIs are relative to the domain, and are usually made “pretty” from the name (and possibly category, date, etc.) of the domain object, for example, Places/Bars/Retro.

That functions well on resource lookup and creation. Resource that needs to be processed is retrieved by querying the database (with the help of Propel ORM) with current request URI. URI of a new resource is concatenated of all the necessary URL-encoded parts.
However, things become complicated when a resource has a lot of child resources, which have the same URI prefix but different ending, for example, Places/Bars/Retro/Events/ or Places/Bars/Retro/Pictures/123 (and there could be hundreds of those). In the current architecture, the only relationship between these resources is the URI string. Now, if a user recognizes he/she has made a mistake, or for some other reason wants to change the name of the place from Retro to something else, it would be also logical to change the URI as well. But that would also affect all the child resources, and changing one name might involve changing URIs of all of them, which could probably mean hundreds of queries. The same goes for deleting.

I don't really see an easy way out of this situation. One of them would be simply not to allow changing names of objects or whatever that goes into URIs :) Cool URIs don't change, right? Made a mistake — create a new one. But I guess that is not too user-friendly, huh?...
The other would mean refactoring the whole resource design by making the parent-child relationship explicit and making the URIs only relative to the parent. Maybe that could be implemented using the new nested-set support in Propel. It would make it easier to get the parent resource (instead of checking their URIs), which is sometimes useful. On the other hand, it would also make resource retrieval, URI matching and constructing much more complicated compared to the trivial string matching and concatenation which is currently used.

Me and my colleague have finally defended our master thesis titled “New Generation of Social Networks and Underlying Web Frameworks Based on Semantic Web Technologies” at IT University of Copenhagen and got 12, the top score on the danish scale. I have to say that was totally unexpected, but still feels nice :)