Restrictive Creativity

Work on my ‘Interactive Outliner’ system is coming along extremely well. I’ve run into a few hurdles here and there, but I’ve gotten through them by focusing on a few key ideas:

  • This is 1.0 – There are features that I want to put in, parts of the system that I want to redesign, more long term planning that I want to do. But that’s what version 2.0 is for. This version just needs to work and get out the door. Real artists ship.
  • Restrictions are good – It is extremely difficult to make something that does everything people would ever need. Damn near impossible. Decide what rational limits need to be and stick with them. If the restrictions are too much refer to the above point.
  • Constantly look for inconsistencies. – This project has its own mojo and it needs to permeate throughout the entire code base. Straying from said mojo is not only bad style but negative progress. Don’t cut corners just to get something done. Do it right the first time.

IOML – Interactive Outline Markup Language

The format I have been working with now has its official name: Interactive Outline Markup Language. IOML.

The IOML format is an evolutionary step from OPML with some of the structure changed to make using outlines, uh, interactive.

IOML is used to communicate with an Interactive Outline Server. The server I am working on is called CoffeeTalk. It is written in Python. Initial coding is almost (damn I’ve been saying that for a long time) done. The feature set is almost frozen. I’m only debating on one more feature before deciding on freezing the specification.

The first clients to use IOML will be in Python, ActionScript 3.0, and JavaScript/Ajax. The Python client is being developed along with the server.

I’m very excited about the possibilities of IOML. It is very flexible, easy to understand, scalable, portable, and, best of all, it just makes a lot of sense.

Development at the speed of thought…

Instant Outlining

I had no idea that Instant Outlining has been around since at least April of 2002. Dave and the team at Userland shipped a version in Radio 8 back then. As always, Dave was ahead of his time.

I first encountered Instant Outlining in August of 2005 when Dave added it to the OPML Editor. I was expecting Instant to mean ‘instant’, but that wasn’t the way things were setup. The OPML Editor would poll the server once a minute to check for changes, which saves a lot on the backend.

From somewhere inside my head came a little voice: “You write server software for a living, why not make an Instant Outlining server that sends updates immediately?” Using the OPML format as a guideline I started putting the pieces together and came up with a proof of concept by the end of August 2005. The name ‘CoffeeTalk’ seemed like a natural fit due to the ancestry from Dave’s love of coffee.

There are a lot of differences between CoffeeTalk and the Instant Outlining tools provided by Dave’s and Userland’s tools. Their tools were/are designed to be open and provide an easy standard for others to adopt. Everything goes through XmlRPC and modifying your web server to handle Instant Outlining is fairly similar to getting your web server to handle blogs. Dave strives to make things easy and accessible.

CoffeeTalk, on the other hand, is not currently an open standard, requires a separate server to be running, has no GUI client to speak of, and no documentation. It also isn’t finished 🙂

I’ll be working on getting version 2.0 finished and ready for internal use in the next couple of weeks. Demos come after that, and then I’ll be figuring out which direction to take things at that point. The next couple of months promise to be very exciting…

and the Client…

Forgot to include something about the client side of things. The only current client is written in Python, but future clients will be coming.

I originally thought the next client would be Java or perhaps an Ajax-ish client, but I’ve been won over by Adobe’s Flex.

So what exactly does the client do besides connect to a server? Clients subscribe to different parts of the ‘outline’ stored on the server and receives updates immediately when a change occurs. This is inspired by Dave Winer’s OPML Editor and its version of ‘Instant Outlining’.

There will be a future post explaining how and why outlines are stored on the server, how subscriptions work, security, etc. For now I’m just getting the engined warmed up…

The Server and the Client

The name of the server for CoffeeTalk is cttpd, the CoffeeTalk Transport Protocol Daemon. This is an obvious take from httpd, the Hyper Text Transport Protocol Daemon.

Web servers, generally, send html files. CoffeeTalk servers send outlines.

Web server connections, generally, are not persistent. CoffeeTalk connections are persistent. Always on.

Always connected clients presents some interesting issues, not the least of which is scalability. There has been a lot of focus and coding put into cttpd to solve the scalability problem. The solutions to this and other problems will be talked about in later posts.

Enough for now…

Super Caffeinated Object Oriented Outline-based Programming

Let’s start with the project I’ll be working on, and coincidentally, the project I’ll be talking the most about: CoffeeTalk. I don’t have a quick 30-second elevator pitch, or even an extended version that can fully explain it. Yet.

I’m still not sure how CoffeeTalk will turn out. The title of this post is one way to look at it. Another is “a scalable network application framework.”

The key points of CoffeeTalk:

– Outline based. This brings inherent organization to applications.

– Object oriented. No explanation needed.

– Network based. No machine is an island. Or “The Network is the computer”

– Client-Server topology. Buzzword compliant, but true.

I’ve already built 2 versions. Version 1 was a pretty bad proof of concept, but it works. It is currently in use.

I’ve released version 2 as an internal test release and it is a significant improvement over version 1.0. The code is much cleaner, there’s actually some documentation, and it mostly works. There are some show-stopper bugs that need to be fixed. I’m not going to fix the bugs in version 2.0, instead I’m going to fix them in 2.1 which will also include a complete rewrite of the networking code.

All of this is currently being written in Python 2.5 using the PyDev plug-in for Eclipse. Quite possibly the best Python development environment I’ve ever used. Makes me feel productive.

More later…