The CMS vendor meme

March 18, 2009

Yesterday my colleague Michal Marth launched a cool CMS vendor meme, challenging other vendors to self-evaluate their products according to the we-get-it-checklist suggested by Kas Thomas.

Many vendors have already responded. Except those who don’t know about Twitter or blogs, of course. You don’t want to buy from them anyway ;-)

To help people find pages related to this meme around the web, I suggest adding the string 9c56d0fcf93175d70e1c9b9d188167cf to such pages, so that a Google query can find them all.

As I said on the dev.day.com post, this number is the md5 of some great software, the first person to tell me which file that is gets a free beer or equivalent beverage!


Looking for use cases for a semantically enhanced CMS

March 10, 2009

iks-logo.jpgDay is participating as an industrial partner in the Interactive Knowledge project, which aims to provide an open source technology platform for semantically enhanced content management systems.

We are starting to collect use cases for a semantically enhanced CMS – although I’m not 100% sure what semantically enhanced means (and I assume that means different things to different people), I have started with use cases like the following:

When I drop an image of a house in my content, the system allows me to see images of similar houses, and pages that talk about houses.

When I start writing a new piece of content, the system optionally shows me similar content that’s already in the repository, even if written in other languages.

The system allows me to formulate queries like “recent pages that talk about houses to rent in the french part of Switzerland”.

If you have additional ideas for such use cases, or examples of systems that provide such features, I’m all ears!


Google Summer Of Code 2009 – Real Soon Now!

March 6, 2009

The 2009 logo is fantastic, isn’t it? Flower power is not dead apparently.

Google Summer Of Code 2009 starts soon, open source organizations can sign up starting March 9th (a very important date planet-wide anyway), and students can sign up starting March 23rd.

An A4 flyer is available to display in your school, or anywhere geeks graze.

Assuming we’re accepted as an organization, projects of the Apache Software Foundation will be listed on our wiki. I’m probably going to suggest one or two Sling-related projects.

Philip Johnson’s video presentation (below) gives a good overview of the program and of its requirements, for students.


Does OSGi work for you?

February 25, 2009

apachecon-eu09.jpgI’m looking for additional input for my Tales from the OSGi trenches talk, at ApacheCon EU 2009 next month in Amsterdam.

My main angle for this talk is how the move to OSGi changes the way developers and customers work. Day‘s complete product line is based on OSGi (using Apache Felix and Apache Sling), and this has a tremendous impact on how our developers work. Users of our products, depending on the level at which they decide to interact with them, can also reap big benefits from OSGi’s modularity and service-oriented features.

However, while OSGi might look like a silver bullet on paper, rethinking modularity and services has an important impact of the way people work, and on how we test our systems.

For this talk, I intend to describe the impact that OSGi has on our ways of working, including the potential downsides, or misuses, of extreme modularity and extreme dynamic behavior of services and components.

I’d be very happy to include other people’s opinions (converging or not) in my talk, so let me know if you have similar experiences to share. Either in comments here, or by mail, bdelacretaz () apache.org. All contributions will be duly acknowledged, of course!


Sling RESTful scripting elevator pitch

January 31, 2009

Just sent the explanation below to the newly created Server-side Javascript discussion group (thanks Lars for the ping).

Such a compact explanation of how Sling processes requests using scripts could be useful on an elevator (you’d need a few floors though), so here it is:

Sling stores data in a JCR repository, which is basically a (potentially large) tree of Nodes and Properties attached to those Nodes, adressable by paths like in a filesystem.

An incoming URL maps to a Resource, which is usually a Node in the JCR repository. That mapping is 1:1 at the path level. Plus extension and “selectors”: a path like /content/foo.print.a4.html points to the /content/foo Node, print.a4 are selectors and html is the extension.

The Resource then defines a “resource type”, usually via a Property of the Node. If our /content/foo Node has a sling:resourceType Property with value “bar”, Sling looks for scripts under /apps/bar to process the request. For the html extension, for example, /apps/bar/html.js is used, if it exists. That could also be /apps/bar/html.rb for a Ruby script, if that scripting engine is installed. For other method names than GET, Sling looks for scripts named after the method, like POST.js or DELETE.js, under /apps/bar in our example.

This gives you RESTful interactions with content, with no configurations or annotations – just drop a script under the right path.


A quick “first impressions” tour of microblogging APIs

January 19, 2009

I had a look at a few microblogging APIs, hoping to find one that’s extensible and RESTful.

That world is fairly fragmented at the moment, which is not surprising considering how new the whole microblogging thing is. Having a common API would be good, and the newly incubating ESME project might be a nice place to make this happen.

I don’t think anyone expects microblogging interactions (except for the very basic ones maybe) to happen directly from a naked browser, so a clean RESTful interface, that does not have to work around current browser’s HTTP weaknesses, should be possible.

Here’s a quick list of my findings – I spent less than an hour on this so it’s just a quick “first impressions” tour. Feedback is welcome, as are pointers to APIs that I might have overlooked.

The Jaiku API uses hostnames to differentiate between users, as in http://johndoe.jaiku.com/presence/json. That won’t work in the general case, you can’t force everybody who installs a microblogging server to setup virtual hosts. The API is also not RESTful when it comes to posting, as it uses method names in request parameters.

The current ESME API is not RESTful, and it uses HTTP sessions. But it’s simple to understand and describe, which is cool – microblogging is not *that* complicated.

The Twitter API is the most complete, and provides various useful formats including Atom and JSON. The resource URLs are nice, but an URL can have a different meaning based on the name of the authenticating user, which is not good for caching, debugging, etc.

Dick Hirsch (who often writes at blog.esme.us) mentioned the Yammer API. The spec is simple and clear, with nice URLs, but like in Twitter a resource URL can have a different meaning depending on the username used to sign the request.

I’m not a REST guru, but common sense makes me wonder why an URL like http://myservice.com/messages.json is better than http://myservice.com/johndoe/messages.json? Expressing the johndoe username in the URL makes it very clear what is what. No username, as in http://myservice.com/messages.json, means “all users” which maps nicely to the public timeline.

I’ll have a closer look, with the idea (at some point) of creating a microblogging server based on Sling. And talk to the ESME folks, as I’m a mentor for ESME’s incubation.

Update: Lars suggests having a look at openmicroblogging as well. Will do.


Using the JCR-Explorer with Sling

January 6, 2009

jcr-explorer-with-sling-200.jpgHere’s how to configure the JCR-Explorer tool under Tomcat, to use it with Sling.

Tested with Tomcat 6.0.18, JDK 1.5 and the Sling launchpad/webapp from revision 731934.

Starting with a fresh Tomcat install, add this to conf/server.xml, inside <GlobalNamingResources>:

<Resource name="jcr/globalRepository"
  auth="Container"
  type="javax.jcr.Repository"
  factory="org.apache.jackrabbit.rmi.client.ClientRepositoryFactory"
  url="rmi://127.0.0.1:1099/jackrabbit"/>

Add this to conf/context.xml, inside <Context>:

<ResourceLink name="jcr/repository"
  global="jcr/globalRepository"
  type="javax.jcr.Repository"/>

Copy the jcr-explorer.war file to the tomcat webapps folder, start tomcat,
stop it (so that the webapp is expanded) and add this at the end of webapps/jcr-explorer/WEB-INF/web.xml, inside <web-app>:

<ResourceLink name="jcr/repository"
  global="jcr/globalRepository"
  type="javax.jcr.Repository"/>

Copy these two jar files to the lib folder (or common/lib for Tomcat 5):
jackrabbit-jcr-rmi-1.5.0.jar and jcr-1.0.jar.

Start Sling with the RMI export of the repository enabled. That’s standard if you start the Sling launchpad/webapp module with mvn jetty:run, for example. Sling can either run inside Tomcat, or standalone, as the connection is made via RMI.

On the jcr-explorer login page (http://localhost:8080/jcr-explorer/login.jsf), use java:comp/env/jcr/repository as the JNDI URL, and admin/admin for login and password.

You should now see the JCR-Explorer page, as in our screenshot, displaying the contents of the Sling repository in the left pane (index.html, sling-logo.png, etc.).

This JCR-Explorer setup can be used to access any Jackrabbit repository accessible via rmi://127.0.0.1:1099/jackrabbit, that should work with plain Jackrabbit setups as well, of course.

See the JCR-Explorer website for more info about how to use that tool.