Month: June 2008

June 30, 2008

Slinging some ideas around RESTful content

Via Seth Gottlieb news that Apache Sling has been officially released. Sling is interesting–I’ve played with it only a bit. You can read more about it on Seth’s post but essentially it is a REST API that sits on top of Apache Jackrabbit. Jackrabbit is the reference implementation of the JCR spec.

I’m not crazy about the JCR API because it is Java-only (yes, I know there are bridges out there). Plus, it doesn’t seem to be rich enough for many types of implementations. For example, Alfresco is a JCR-compliant (Level One) repository, but you don’t see too many people doing JCR-only interactions with Alfresco.

What is interesting to me, though, is the idea that you can abstract repositories at a higher level: the REST API. If we’re all going to talk to our repositories via REST, why not do it in a standard way?

Alfresco introduced a REST framework in 2.1 called “web scripts” (learn more). But Alfresco does not yet have a full-blown “REST API”. Yes, there are a few out-of-the-box REST calls but for the most part, when you interact with Alfresco via REST you are going to roll your own API. On Optaros projects, this has not yet been a huge burden. Quite the opposite, in fact–we’ve been able to develop everything from web script-backed JSR-168 portlets to a streamlined version of the Alfresco web client (soon to be released as an open source project), all on web scripts.

As part of 3.0, Alfresco anticipates rolling out additional out-of-the-box URLs to more fully establish the REST API. The new 3.0 web clients are based almost entirely on REST so they might as well build a REST API that we can all use.

When I look at Apache Sling, I’m thinking, why don’t we agree on a standard REST API for working with content repositories. Then, we could write a front-end once and theoretically use it with multiple back-end repositories. If someone then wants to use a JCR-compliant repository behind the scenes, then that’s cool, but it isn’t a requirement.

Obviously, there is a granularity challenge here. If the API is too granular the front-end ends up making too many calls. If you are aggregating multiple calls from within an intermediate application and then returning the result to the front-end (rather than making a bunch of AJAX calls initiated from the browser client), that’s not as much of an issue. If the API is too coarse, it is too hard to reuse across many different types of front-end applications.

Still, if we agree that REST is the preferred interaction model in the “content as a service” world, at least for the moment, and further, that front-end developers tend to want to have the option of using non-Java technologies for the presentation layer, a standard REST API for interacting with content repositories makes sense, whether that’s Sling, whatever Alfresco comes up with, or the best of both.

Maybe the Atom Publishing Protocol is close to what I’m thinking here. Maybe Alfresco thinks so too. I noticed the Abdera JAR was added to the Alfresco Community dependencies fairly recently. Abdera is an Apache incubator project for working with Atom.

We actually have an engagement with Alfresco right now to develop some of the new 3.0 web client modules. When I get some time I’ll explore this idea a little further by checking in on the 3.0 web client team, looking at Abdera, and doing a deeper dive on sling.

June 26, 2008

Toughest ECM Job: VP of HR at Vignette?

Quick, name an Alfresco SE who did not come from Vignette. Okay, you can shout out any name you want–I don’t really know the answer. But it does seem like every week I’m meeting an Alfresco new-hire that just turned in his Vignette badge. Most companies have an “attrition” number they keep an eye on. Vignette must have a “left to go to Alfresco” metric that keeps those guys up at night.

Of course the market is relatively small and incestuous and everybody’s gotta have a former employer, but I know when someone leaves you always want to know where they are going and if it turns out to be a competitor, it puts a pit in your stomach.

I guess as the legacy commercial ECM vendors get taken down by Alfresco and, more generally, the open source movement, this kind of thing is going to happen and it will get even worse. It’s kind of like watching Animal Planet. You see the tiger stalking the gazelle, you know what’s coming and you know it is the “circle of life” and all of that, but when the claws inevitably sink into those fleshy hindquarters, you still have to feel something for the gazelle, even if only for a moment. At least until you realize that’s what the gazelle gets for not embracing open source.

Of course hiring a bunch of folks from the same company doesn’t always work out for the best. People tend to be loyal and they move in packs (don’t worry, no one’s getting eaten in this metaphor). For example, someone recently connected the dots for me with regard to the Alfresco WCM engineer departures. It turns out Kevin Cochrane, Britt Park, and Jon Cox all came over from Interwoven so the timing of their departures is not coincidental at all.

June 10, 2008

Kevin Cochrane leaving Alfresco

In his blog, John Newton announced yesterday that Kevin Cochrane is leaving Alfresco. This was a bit of a shocker. If you’ve ever been to any sort of community event sponsored by Alfresco, chances are you’ve heard Kevin speak. In fact, if you’ve been involved at all in strategic discussions with Alfresco about product direction, you can attest to the passion an enthusiasm Kevin exudes when discussing Alfresco. Excitement alone would make him just a Marketing guy (no offense, my Marketing friends!), but Kevin added to that a sharp sense of direction for where Alfresco was headed and what users were looking for. That combination is what made him a good product manager, not just for Alfresco WCM, but really the entire platform. As John mentions, the product really wouldn’t be where it is today without Kevin’s drive.

It always seemed odd to me that Kevin, with his strong Interwoven background, was driving both the WCM and DM side of the platform. It seemed like a lot of scope to bite off, particularly with the potentially diverse set of use cases each provides. I guess The Two Johns agreed–they’ve decided to backfill Kevin with two resources: Mike Farman for ECM and Michael “Uzi” Uzquiano for WCM. Uzi earned recognition of late with the creation of the “next generation” web site framework which ultimately was adopted into 3.0 and incorporated into the plans for the new 3.0 web client, so he’s got the technical chops.

It’ll be interesting to see what happens next. Kevin’s is the latest departure from the Alfresco WCM ranks. A month or so ago two senior WCM engineers, Jon Cox and Britt Park, left. There seemed to be a bit more proactive damage control being done when Jon and Britt left, but I’m not going to read anything into that.

Alfresco has a lot of momentum right now with key clients going live on both the DM and WCM side of the house, impressive subscription revenue growth, and a good team to fill the void left by Kevin and Co. Provided the 3.0 release doesn’t slip too terribly far behind, I don’t think these departures are going to derail them.

June 4, 2008

Fixed the Alfresco-Ringside File Upload Problem

I’ve been playing with Ringside‘s Social Application Server. In my initial post on the subject I mentioned I was having trouble with the file upload. I got that put to bed this evening. As it turns out, Facebook inserts some hidden fields into form tags (see doc) such as the Facebook user, API key, session key, and app ID. Ringside doesn’t insert those fields.

Why does this matter? When you post a multipart form (i.e., a file upload) in a Facebook app, you don’t post to the canvas URL, you post to the application directly, which in this case is an Alfresco web script. All other posts go through the canvas URL and by the time they arrive at the web script, the request has the parameters it needs to make Alfresco’s Facebook web script runtime happy. In Ringside, the file upload post lacks that context because the hidden fields are missing. Alfresco needs those hidden fields–without them, the script has no idea which Facebook app is posting the data.

The fix was easy enough. I just inserted the hidden fields into the form via the Freemarker template (adddocdialog.post.fbml.ftl). The “facebook” root object knows the user, API, and app ID because the form gets displayed as the result of a canvas post.

Here are the hidden fields I added to form in the Freemarker template:
<input type="hidden" name="fb_sig_user" value="${facebook.user}" /><input type="hidden" name="fb_sig_session_key" value="${facebook.sessionKey}" /><input type="hidden" name="fb_sig_api_key" value="${facebook.apiKey}" />

The only other change I made was to comment out the postUserAction call in adddoc.post.js. I’m not sure that’s supported yet in Ringside. If it is, there’s some other problem causing it to choke.

So, other than the user action post, the Alfresco Document Library Facebook app is fully-functional in Ringside.

The next step is deeper integration into the web client. I know Alfresco is moving toward more social networking features in the 3.x release, but integrating with Ringside via web scripts might be a way to get there faster with more functionality.

June 1, 2008

Alfresco and Ringside

I’ve made moderate progress getting Alfresco and Ringside integrated. If you haven’t played with it yet, Ringside Networks is an open source project that essentially gives you a standalone Facebook server. There’s actually more to it than that, but for this conversation, what matters is that Ringside supports the Facebook API and FBML without requiring a connection to Facebook.My goal is to get the Alfresco Facebook “Document Library” example (screencast) working in Ringside. What I have working now is single sign-on between Alfresco and Ringside, the main web script, the document library creation web script, and the document libraries list web script (pictured). What isn’t working so well (yet) is the file upload.

If you want to try this yourself, you’ll need:

A working install of Ringside Networks Social Application Server (Advanced Developer Setup instructions) which requires PHP and MySQL
A working install of Alfresco Community
The Facebook AMP (or just the web scripts from the AMP) or your own set of Facebook runtime web scripts
Alfresco Community SDK & Source

Alfresco has hardcoded Facebook URLs into the FacebookAuthenticatorFactory and FacebookModel classes. You need those to point to your local Ringside server instead of Facebook. I created a RingsideAuthenticatorFactory which is just a dup of FacebookAuthenticatorFactory with LOGIN_REDIRECT changed to:
"<fb:redirect url=\"http://localhost/api/login.php?api_key=%s&v=1.0%s\">"
You’ll need to override the webscripts.authenticator.facebook bean with a pointer to the new class, like so:
<bean id="webscripts.authenticator.facebook" class="com.optaros.ringside.RingsideAuthenticatorFactory" />
I took a more hackish approach to the FacebookModel. I removed Alfresco’s class from alfresco-webscript-framework.jar and replaced it with my own version that has updated getCanvasURL and getPageURL methods:
public String getCanvasURL() { return "http://localhost/web/canvas.php/" + getCanvasPath(); }

public String getPageURL() {
return “http://localhost/web/canvas.php/” + req.getPagePath();
}

At some point, what should really happen is that all of these URLs should be pulled out into a config. Once I get everything working, maybe I’ll circle back with a better step-by-step and perhaps the changes can be submitted to Alfresco so that it is easier for people to choose whether their Facebook web scripts run against Facebook or a Ringside server.