Weblog: Archive

Chris Messina has a pretty good story comparing Apple's Magic Mouse and the recently announced OpenOfficeMouse that was targeted to power users of OpenOffice.org:

At base, these products represent two polar opposite ends of the spectrum: Apple prefers to hide complexity within the technology whereas the open source approach puts the complexity on the surface of the device in order to expose advanced functionality and greater transparency into how to directly manipulate the device. Put another way, the reason that people would buy the $69 Apple MagicMouse is because they want Apple’s designers to just “figure it out” for them, and provide them with an instantly-usable product. The reason why someone would pay $75 for this mouse is because it strictly keeps all the decision-making about what the mouse does in the hands (pun intended?) of the purchaser.

What I worry about, however, is that pockets of the open source community continue to largely be defined and driven by complexity, exclusivity, technocracy, and machismo. While I do support independence and freedom of choice in technology — and therefore open source — I prefer to do so inclusively, with an understanding that there are many more people who are not yet well served by technology because appropriate technology has not been made more usable for them.

More focus on usability and clarity would be needed with most Open Source projects, but there are already some bright spots. GNOME, for example, has good tradition in simple interfaces. I recently made the jump from Mac OS X to Ubuntu Netbook Remix, and have generally been quite happy with it.

But for Open Source projects the challenge is more difficult than for proprietary products. On the other hand we want to provide a nice, usable experience, but we also want to let our users delve deeper into the functionality, to make changes and maybe even become contributors to the project. This is where new tools like OLPC's View Source button can do wonders if implemented more widely.

An increasing number of web services and applications are emphasising search terms or pre-selected websites instead of allowing users to enter any address they choose. This is worrying, as while searches are more user-friendly, URLs are the heart of an open web where anybody can publish without obscure business dealings or oppressive app store policies.

There are many examples of this happening, from Facebook's framing of web to netbooks systems like the JoliCloud not having an address bar. Certainly many companies are looking at Mozilla's search engine revenue and Apple's app store model and want to emulate that, moving the web into silos of their own control. But at the same time, we're thinking of Linked Data and open, interoperable web standards.

Web indeed is at new crossroads.

Chris Messina predicts the death of URLs:

a future without URLs and without the infinite organicity of the web frightens me. It’s not that I know what we’ll lose by removing this artifact of one of the most generative periods in history — and that’s exactly the point! The URL and the ability for anyone to mint a new one and then propagate it is what makes the web so resilient, so empowering, and so interesting! That I don’t need to ask anyone permission to create a new website or webpage is a kind of ideological freedom that few generations in history have known!

Tim O'Reilly presents a call to arms:

It could be that everyone will figure out how to play nicely with each other, and we'll see a continuation of the interoperable web model we've enjoyed for the past two decades. But I'm betting that things are going to get ugly. We're heading into a war for control of the web. And in the end, it's more than that, it's a war against the web as an interoperable platform. Instead, we're facing the prospect of Facebook as the platform, Apple as the platform, Google as the platform, Amazon as the platform, where big companies slug it out until one is king of the hill.

And it's time for developers to take a stand. If you don't want a repeat of the PC era, place your bets now on open systems. Don't wait till it's too late.

Mjolnir, the new major release of Midgard2 Content Repository is now out. Named after the hammer of Thor, this release finally provides a real content repository that can be used by both desktop and web application developers.

In addition to being a GObject-powered content repository for PHP, Python and Objective-C, the Mjolnir release provides several significant goodies on top of the older Midgard2 series:

• MgdSchema Views provide a way to define joined data types
• MgdSchema types can be extended with subclasses and additional information
• Transactions are available for storage engines that support them
• New authentication API provides support for different types like OpenID and OAuth
• ...and there are a lot more unit tests, helping to safeguard against regressions

We've been testing running the Qaiku microblogging service with Mjolnir. The exactly same PHP code that we used with Midgard 8.09 LTS performs 20-60% better when running on Mjolnir.

Get Midgard2 9.09 Mjolnir while it is hot! Builds for various Linux distributions are already starting to hit OBS repositories...

Joint post of Henri Bergius and Michael Marth cross-posted here and here.

Web Content Repositories are more than just plain old relational databases. In fact, the requirements that arise when managing web content have led to a class of content repository implementations that are comparable on a conceptual level. During the IKS community workshop in Rome we got together to compare JCR (the Jackrabbit implementation) and Midgard's content repository. While in some cases the terminology might be different, many of the underlying ideas are identical. So we came up with a list of common traits and features of our content repositories. For comparison, there is also Apache CouchDB.

So, why use a Content Repository for your application instead of the old familiar RDBMS? Repositories provide several advantages:

• Common rules for data access mean that multiple applications can work with same content without breaking consistency of the data

• Signals about changes let applications know when another application using the repository modifies something, enabling collaborative data management between apps

• Objects instead of SQL mean that developers can deal with data using APIs more compatible with the rest of their desktop programming environment, and without having to fear issues like SQL injection

• Data model is scriptable when you use a content repository, meaning that users can easily write Python or PHP scripts to perform batch operations on their data without having to learn your storage format

• Synchronization and sharing features can be implemented on the content repository level meaning that you gain these features without having to worry about them

Firebug is a Firefox extension all web developers are familiar with. Now when developing with the MidCOM3 MVC framework it is possible to get your debug information straight from Midgard to Firebug:

This is built on top of the excellent FirePHP extension, which helps you get data not only from regular web pages but also from AJAX requests.

Currently we send all logged information plus details about current route and templates being used. To use this, install FirePHP in your Firefox, FirePHPCore from PEAR packages, and enable development_mode in MidCOM3 configuration.

I'm considering to port this also to Ragnaroek.