<xml.lt>

I've been working more with Java than PHP recently, using a Java port of the DIY Framework. So effectively it is a portable framework now, at least to some extent — it is a matter of language syntax and model layer to move a Web applicaton between Java and PHP.

Not that this is going to be extensively used killer feature. But I think it is a positive outcome of our Web framework design: it has to be based on HTTP and REST principles and concepts. Since they are uniform for all Web applications, such a framework makes them portable.

We think it is essential to incorporate HTTP at the heart of the design, and in the DIY Framework an URI-adressed Resource is an actual class. It is also for the same reason we don't like or use third-party frameworks, since instead of HTTP, they are built on concepts taken out of the blue. Symfony structures an application as modules and actions and throws a mess of routing on top. Who said that a Web application must have structure like that? Apache Struts uses some abstract notion of action and tons of configuration. ASP.NET goes even further and pretends it is used to build event-driven Windows applications and not Web applications of request/response nature.

This is pretty old news dating back to this spring, but the Danish IT and Telecommunications board (IT- og Telsestyrelsen) has published an experimental REST interface OIOREST for public data such as regions, municipalities, post codes, schools, streets, and addresses. And example of a query identifying a street: http://oiorest.dk/danmark/veje?q=frankrigsgade.

OIOREST is a great initiative, and we hope it will be expanded to other datasources. There is one big concern though — it is not employing established data standards but instead using its own custom XML schemas.
What they should really consider is publishing the data as RDF in the Linked Data manner. That would make Denmark one of the pioneers not only in REST adoption, but also in the Semantic Web.

One of the outstanding issues in the updated (so far internally) version of the DIY Framework, which now keeps resources in a hierarchy, is how to effectively calculate the full URIs of resources. For this post, it would be Blog/2008/09/16/Computing+path+of+a+node+in+a+hierarchy, where the post resource is a leaf node with a depth of 5. In general terms, the question is how to calculate path of a node.

Propel's nested sets implementation for some reason calculates the path by recursively traversing from the node to its parent and so on until the root is reached, although this can be done using one SQL query. But even one query per resource is not good enough, since usually one page would use tens or even hundreds of resource objects.

In order to improve performance and not to compute the URI on every load, we left the full URI property for resources as it was, in addition to the new relative (to parent resource) URI property, and properties needed to implement the nested sets. So the question is, how to keep the full URI up-to-date all the time with resource's position in the tree? It certainly needs to change when one of the ascendant (parent, parent of the parent etc.) resources, or the resource in question itself, is moved or updated. But that might also involve a chain reaction since full URIs of descendant resources would also need to change, and they might be in numbers of hundreds or thousands. Definitely a performance problem, especially if done on the PHP level. I was thinking about implementing this with SQL triggers somehow, but it doesn't seem to be so trivial. Anyone has ideas?

For those who missed it, the new Google Chrome browser is already available for download. Appeared almost out of blue sky, hopefully it will help to further push the market share of Internet Explorer.
The beta version seems pretty stable and solid. There are also reports that its new V8 JavaScript engine (built in Aarhus, Denmark) is multiple times faster than those in other browsers.

We recently internally redesigned our framework framework. Now the resource objects form a parent/child tree, where each resource is a node and contains its URI relative to the parent (instead of full URI relative to the host, as previously). The hierarchy was implemented using nested set support in Propel, which is way more efficient than the ID/parentID method that requires recursion and lots of database queries. The tree of our page would be:

• www.xml.lt (although the tree is actually hostname-independent)
  • Blog
    • 2008
      • 08
        • 20
          • Resource tree (this post)
        • ...
      • ...
    • ...
  • Resources
    • Framework
    • ...
  • Services
  • ...

This means that now resources can be treated as files and folder in a filesystem — copied/moved from one URI to another, renamed, given permissions etc. A sitemap of the site can be generated automatically. Of course, as before, they can be related to domain model objects which they stand for.

While developing a RESTful webservice, I realised I need some kind of authentication to only allow clients to execute certain HTTP methods on certain resources. For example, a client should only be able to able to GET/PUT its own placemarks at /placemarks/client1 but not others at /placemarks/client2.
In a regular Web application this would be solved in a simple way using sessions. But one of the REST principles is statelessness, which eliminates cookies and sessions. So this might be an old question, but what is the common authentication method between a client and a RESTful webservice? Is HTTP Basic/Digest enough here?

We started working a little bit with location-based services. One of the tasks was to create a webservice endpoint to serve placemark information for a certain location. We chose Google's KML (Keyhole Markup Language) as the representation format. It has become an official Open Geospatial Consortium (OGC) standard.

This piece of code might be useful for those who have a similar need to serialize placemark objects in to KML. It is using PHP's Document Object Model (DOM) extension.

$doc = new DOMDocument("1.0", "UTF-8");
$kmlElem = $doc->createElementNS("http://earth.google.com/kml/2.2", "kml");
$doc->appendChild($kmlElem);
$documentElem = $doc->createElement("Document");
$kmlElem->appendChild($documentElem);

$places = PlacePeer::doSelect(new Criteria()); // retrieve placemark objects, e.g. from Propel model

foreach ($places as $place)
{
	$placemarkElem = $doc->createElement("Placemark");
	$documentElem->appendChild($placemarkElem);

	$nameElem = $doc->createElement("name");
	$placemarkElem->appendChild($nameElem);
	$nameElem->appendChild($doc->createTextNode($place->getName()));

	$descElem = $doc->createElement("description");
	$placemarkElem->appendChild($descElem);
	$descElem->appendChild($doc->createTextNode($place->getDescription()));

	$pointElem = $doc->createElement("Point");
	$coordElem = $doc->createElement("coordinates");
	
	$coordElem->appendChild($doc->createTextNode($place->getLng().",".$place->getLat().",0"));
	$pointElem->appendChild($coordElem);
	$placemarkElem->appendChild($pointElem);
}

$response->write($doc->saveXML()); // use the KML string, e.g. write it out to response

Back from some holiday, I was thinking about how to (automatically) manage user-generated content. On a website where users can add and change data, how does one make sure that it is entered correctly and that it will not be vandalized afterwards? Maybe I am paranoid, but I think if there is a possibility to ruin something online, it will be ruined.

Let us take a website where users can add events and their details as an example. What if an event is fake? Also, what about duplicates (different names for the same actual event)? Last.fm takes an interesting approach letting users vote for the right names of the artists. After some number and/or percent of positive votes, it would be possible to assume that event details are correct and lock it to prevent further editing.

But what if the event details actually need to be changed? Should only the creator be allowed to make changes, or everybody? In that case, how to make sure that a description carefully crafted by several users will not be wiped out by somebody? As far as I can see, it needs at least some version tracking to be able to roll back to the right version, as in Last.fm's description wiki and Wikipedia. But the implementation on a relational database does not seem trivial for me. Can anyone provide an example? I think it would be possible to build version tracking into existing ORMs such as Propel.

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.