We've been mentioning, here and there, an impending release of a REST API for Socialtext. As soon as next week, the code and docs will be close enough to say, "let's do a Beta." Watch here and on the Socialtext Open Source Wiki for an announcement explaining how to participate. We'll be providing free workspaces to developers that don't already have their own.

What can you do with a REST API to Socialtext? We don't really know. Sure, we have things that we want to, and will, do with it to improve our systems, but because it is RESTy and because we designed it to be this way, it is very flexible and general. The data is there, you do what you want.

Here's some things we've already done:

• Socialtext::Resting, an evolving Perl library for manipulating the resources presented by the API. The distribution includes strut, a command line diddle-your-workspaces tool. Kirsten Jones and I (Chris Dent) built Socialtext::Resting.
• News Boy, put together by Zac Bir and Matt Liggett, is a desktop application for OS X for browsing Socialtext content on multiple servers. We'll get editing added in the next few days, and release it when the Beta starts.
• The Violator, a prototype AJAX interface to Socialtext. It's called the Violator, because thus far it blows away any sense of good browser accessibility behavior. Look for this on the Socialtext Open Source Wiki in a few days.

Some ideas we've had, but need more time, help or encouragement to complete:

• Adaptors for moving information between database systems such as SugarCRM and a Socialtext workspace, allowing more flexible tracking of customers, products or whatever else.
• Restaurant reviews in a Socialtext Wiki, created in a mashup with Google Maps. Go both directions: find restaurants on the map and read or create reviews, or read and edit reviews and then find them on the map.
• Using the API to generate an IMAP interface to Socialtext: Wiki in your mail!

I'm sure Socialtext users have plenty of ideas. If you want to give your ideas a shot, watch this space for more info, and watch the Open Source Wiki recent changes for developments. We're looking forward to the fun.

• |
• Permalink

In the documentation for the new SOAP Service we make use of a relatively new feature in the Socialtext Wiki markup: the ability to include one page within another. If there's some chunk of content that is or will be useful in more than one place (for example the impersonation description page in the soap documentation) we "extraclude" the content to its own page and then include it in multiple pages.

In hypertext tools this functionality is usually called Transclusion. Content is stored in one place but used multiple times in multiple places to create multiple documents or narratives.

At Socialtext we use the term quite loosely (because it's useful to us that way) to refer to having stuff over there that gets used over here. When we update it over there we see the changes over here. Including one or more pages inside another page is a form of transclusion, and so is including the contents of an Atom or RSS feed. Transclusion, in whatever form you get it, allows the dynamic composition of complex documents from smaller pieces.

I started playing with transclusion when I implemented it for Blueoxen's experimental Purplewiki platform. In Purplewiki, individual paragraphs and list items can be transcluded at a granular level meaning an author can pick and choose small pieces from another large document. Socialtext is not there yet, but we're making steps in that direction, choosing simple changes with immediate value. Someday soon, I hope we'll be able to do dual-ended transclusion, where editing is possible on both ends of the transclusion link.

The SOAP Service and our forthcoming REST API allow a similar kind of transclusion: Content stored in a Socialtext wiki can be presented in other systems including web portals, desktop applications and specialized interfaces.

It's easy to look at transclusion as a geeky hack--it's pretty cool to wiggle some content over here and have some stuff over there change--but that's not really the point. Transclusion is one of several tools (like Wikis themselves) that enhance our ability to make use of the information and understandings emerging in a group's communication and narrative.

--Chris Dent

• |
• Permalink

According to Jonas, who is at LinuxWorld with miscellaneous and sundry members of the Socialtext crew, people are asking about our new SOAP service. Meanwhile, back at the lab, we've been having some fun with it.

John Thompson, the primary sysadmin, has put together a quick Socialtext filesystem using FUSE and the SOAP server. List, copy and edit pages in a workspace right on the commandline with familiar tools.

I've thrown together a very quick search interface that searches multiple workspaces on multiple servers.

Matthew O'Connor made a simple wiki interface to a Socialtext workspace using Ruby on Rails, the SOAP service and a dash of HTML and CSS fu. You can search, edit, see recent changes; do all the basic wiki stuff.

For this week only you can feel free to give the rails client a spin and remember it was built in less than a day.

The SOAP service has provided us with another tool in our box for solving problems and manipulating workspace content.

If you want to use it too, you can get access to the SOAP service in a variety of ways: Read the documentation to see how to create clients to your existing workspaces; try out Socialtext Open; or talk with your representative at Socialtext.

But wait, there's more! We've also been working on our data oriented API. We're calling it REST at the risk of inviting criticism. We hope we get it right. We shall see, sometime in early Fall.

Our REST framework is based on Matthew O'Connor's REST::Application package. He and Matt Liggett have set things up so it is very easy to represent our core resources in useful ways.

Although we're not quite done with the API, we've started some clients. Zac Bir and Matt Liggett have built News Boy, a desktop PyObjC client to Socialtext that lets you track and view workspace content from an OS X machine. We'll release it when the REST API goes beta.

Kirsten Jones has started strut (SocialTextRESTUnifiedThing), a command line tool for putting stuff in workspaces. Kirsten says, "That's right, 'strut'. Because that's what we all feel like doing when we play in this code. Strutting about." strut is designed, in part, to help people import converted data from wiki systems into Socialtext.

These tools exist at a remove from the core Socialtext system. There is a well defined and simple interface between them allowing each to evolve independently.

Which is rather the whole point.

Chris Dent

• |
• Permalink

A couple of weeks ago many of my coworkers were sweating it out in Portland at OSCON where Socialtext announced that the socialtext code base is available for download by anybody, whenever they like.

This is cool and all, and I'm very proud of us for doing it, but the part I like most about the announcement is toward the end:

Socialtext also announced its new Simple Object Access Protocol (SOAP) Application Programming Interface to enable developers to integrate and extend Socialtext Open. Documentation is available at http://socialtext.net/stoss/?SOAP_API

This is yet another piece of the pie in opening up the system. Open code matters, but so do open systems and open data. The SOAP API is one phase in multiple phases of work happening to make it easy to get stuff in and out of Socialtext; to play in the growing pool of tools that take stuff from here and there, fiddle around a bit and put it there and here. This is what makes the internet fun and most useful. The last time I got this excited about remote API stuff for Socialtext the tools that were created never made it out to the world, mostly because the Atom Publishing Protocol wasn't quite there yet (it's damn close now) but also because the Socialtext side of the code wasn't out there.

The situation is different now: SOAP has been around for awhile; the Socialtext code is released; and the SOAP service is included in Socialtext Open. It's tweakable.

But wait, that's not all. SOAP is not everybody's favorite (certainly not mine). Coming early fall, a far more featured REST-based API (with at least some segment of APP support). You get the data so you can make up your own methods. Some good fun will come of this.

-- Chris Dent

• |
• Permalink