Weblog: Archive

I've been following the Java Content Repository story since the OSCOM conferences of old. Last week, I took a new look at it as Bertrand Delacretaz from Day held a JCR presentation in the Interactive Knowledge Consortium meeting. And you know what? Midgard and JCR resemble each other quite a lot:

• Both follow a repository-centric approach, where the content repository is the point of integration between different tools and applications, with signals flying to inform about actions performed. In JCR this is done with Java events, and in Midgard with D-Bus signals.
• Both are tree-based, enabling objects to be accessed either via their path in the tree, a UUID, or various queries. With JCR, the queries are typically XPath, while with Midgard there is the Query Builder.
• Both also provide a reasonably simple way to define new data types. In JCR's case the Node Type Notation has a somewhat Ruby-like syntax, while Midgard's MgdSchema uses XML. Unstructured data is supported in both by extending the content objects with additional attributes.
• Both provide the notion of a workspace, an ability to have multiple "virtual repositories" within one installation. In Midgard, this was originally implemented to support easier hosting and is called "Sitegroups".

There are some important differences, though:

• JCR is a Java-centric specification, with Apache Jackrabbit acting as the reference implementation. Midgard has only one implementation, but with bindings to multiple programming languages like Python, PHP and C#, allowing developers to work with the tools they are familiar with. Midgard APIs could of course be reimplemented natively in any of the languages, as was done with pure-PHP Midgard-Lite years ago.
• In JCR, everything is stored in a single content tree. In Midgard, the content tree can be multi-rooted, and there can be "independent" objects that exist outside the tree hierarchy.
• The JCR specification allows for version control, which in Midgard is handled using external tools.
• Midgard supports content replication, which JCR does not.
• Midgard handles internationalization of content objects as part of its API, but does not support multivalued properties as JCR does. To bridge this gap between the two repository APIs, I have posted a series of feature requests to Midgard's tracker.

Even with these differences, Midgard and JCR remain surprisingly similar on the conceptual level. It would be an interesting experiment to finally create the Midgard-JCR bindings that Jukka Zitting started long time ago.

Technorati Tags: jcr, midgard, repository

From the bubble-era start-up times in 2001, Nemein has based its invoicing on hours used, as is typical in the software consulting industry. The company provides services on a 100% pure, organic free software stack, and therefore there are no other additional costs beside maintenance on top of the normal work hours used for a client's benefit.

With some clients we invoice as we go, and with others everything is based on tight budgeted amounts of hours. However, as Cory Doctorow's 2001 essay on the utopia of Semantic Web reminds, humans are notoriusly bad at estimating the time something will take, and so often the resolution of a full or half hour is too strict for accurate estimation.

This, and the tediousness of time tracking has kept me looking for a better way. And such a way presented itself when having some discussions over coffee and cognac at a dinner party held in the Nokia Manor: how about stopping obsessing about strict amount of hours, and starting to use a bit more flexible model?

Following the Getting Things Done doctrine of allowing only "actionable" tasks, we would split every project into a group of tasks, each provided with a ballpark estimate labeled with terms common from the clothes industry:

• S: small, simple tasks that can be accomplished in around one hour
• M: tasks requiring a bit more concentration that often take around half a day
• L: tasks requiring lots of focus

We could've taken this to extremes and allowed XXL tasks, but again, to keep things actionable, it is better to split larger efforts into more manageable chunks.

Moving away from strict definitions of time used also would allow us to do something quite appealing: estimate the impact of a given task, the benefit a client will receive from it, and use that as the basis of invoicing.

Of course, this all will not free us completely from the evils of hour reporting. Finnish employment law requires us to keep track of working hours to make sure overtime is compensated, and many of the freelancers working with us bill us by the hour. But now this hour reporting will be greatly simplified as you can just "clock in and out" at the start and end of the working day instead of trying to keep track of various half hour bits and pieces.

And instead of tracking how much time we've spent at the office, we can start measuring the tasks accomplished for our clients. And that should be the more important thing for a consultancy.

Technorati Tags: nemein, gtd

Good work, Debian Project: Debian GNU/Linux 5.0 is released!

As Midgard release manager Piotras wrote in his Jaiku:

debian Lenny (5.0) is out.
It means vinland will run on stable debian.
It means we have php5-xcache in stable debian, we have solr in stable debian.
It means we can think about Midgard in official 'squeeze' (debian testing)

Big step indeed, making it possible to produce similar smooth Midgard experience for Debian as we now do for Ubuntu Server.

Technorati Tags: debian, midgard, ubuntu

Thanks to the IKS project, I've spent some thought lately in how to make something practical from the concept of Semantic Web.

As always, the big issue is getting the semantic information out there. In a strongly typed CMS like Midgard, many semantics can be gathered from content structure directly, but to really get there we need users to add metadata. And as users are lazy, this will happen only if it provides some direct benefit: just look at how frequently people tag their photos on Facebook. Irritating or not, this happens because the tags are actually used to promote the pictures in the news feeds of tagged people.

For this to happen in the web in general, we need to start having the search engines leverage the semantic information. Yahoo! already does this to some extent, making use of microformats and RDFa in Yahoo! Query Language and in the Search Monkey engine. This means we can already do simple semantic queries like "pages mentioning Bergius in the Helsinki area":

Actually, the Yahoo! results are quite interesting:

• My web page (which shows my current location, so it may depend on time indexed)
• Some Chinese(?) spam site that syndicates my content, proving that also in the Semantic Web people lie
• Some Plazes entries about me located in Helsinki
• Midgard events held near Helsinki

Since search engines (well, Google really) are the way people access the web, search engines are the key for making semantic information more widely available. Just look at DeWitt Clinton's survey of rel values from yesterday: Google-defined rel="nofollow" is the most popular rel value out there, even surpassing style sheet declarations. This if nothing else shows the power of search engines in promoting new standards.

Technorati Tags: google, iks, microformats, yahoo, rdfa, search, semanticweb

Jaiku, the microblogging service I use, has been frustratingly often down in the last couple of days, apparently kicking off another mass migration towards Twitter and Brightkite.

And they report it only in human-readable way, not in fashion a browser, a proxy or a search engine would understand it. While being down, Jaiku still responds with HTTP 200 OK:

HTTP 503 Service unavailable would be much nicer. For instance, that is what Midgard produces if the database goes down.

Technorati Tags: brightkite, jaiku, http, twitter

Benjamin Otte is asking on Planet GNOME why the GNOME desktop doesn't do more to integrate with the cloud. He reasons that:

...GNOME developers are not “web-enabled”. We’re a bit like Microsoft in the early 90s: We focus on the local computer and ignore the internet.

which, to my experience is somewhat true. I went to GUADEC for the first time in Dublin in 2003, with the specific mission of promoting integration between desktop applications and the various open source web tools like CMSs and CRMs. However, nobody really seemed interested at the time. Only now that cloud has been hyped for a long time, people are paying attention.

However, just integrating with Google's services is not enough for free software to do. Let me post a slide from the Midgard 2 - The cloud you can control presentation in last FSCONS:

The point we were making there was:

...the cloud is a trap that will move your data, and your applications beyond your control to proprietary data servers and web applications run by multinational corporations. If free software doesn't provide a compelling answer to that, we risk irrelevance.

The answer?

Users flock to the cloud for two primary reasons: collaboration and convenience. Most "cloud apps" allow users to share data with each other and work collaboratively. From the Sugar project, GNOME already has technology for that, if it only was integrated in more applications.

Convenience means that you can access and manage your data from anywhere, using your own device. It means not being tied to a desktop computer somewhere in your home or office. For that, we suggested that Midgard2 could provide a solution:

A replicated, peer-to-peer system of synchronizing and sharing your data could be the answer. And Midgard2 is a framework providing just that. Bindings to different languages like PHP, Python and Mono, interprocess communications via D-Bus and XMPP, replication, and ability to run the same software from big server clusters to Nokia internet tablets should all help us get there.

If applications used Midgard's content repository for their data storage needs, it would be easy to synchronize the data between the user's all devices, and also make it accessible on the web thanks to Midgard's web roots.

Technorati Tags: dbus, freesoftware, gnome, p2p, cloud, telepathy

To make the GNOME desktop more user-friendly we should utilize context information in more places. And now that laptops are becoming more and more mobile, location is one important part of that context. For that, we developed GeoClue, the location framework that is in incubation for GNOME Mobile.

Today I was talking with a student who wants to work on GeoClue GNOME integration in the Google Summer of Code, and here are some ideas we discussed:

• Changing the clock time zone based on location (Jussi already has a patch for this that needs to be cleaned up and submitted)
• Changing weather applet to show weather for current location
• Telling Tracker about the location where documents were edited so you can ask "give me the documents I edited in Stockholm"
• Making Gwibber send the current location to microblogging services that support it
• Showing where your Evolution contacts are (and what their local time is), based on Empathy's XMPP location support
• Setting instant messaging availability status based on location ("set my work account as offline when I'm home")

These are just some examples of how GNOME could serve users better if the desktop applications knew where they are. Web applications are already getting this capability, and the desktop shouldn't be left behind.

Technorati Tags: geoclue, gnome