Friends have launched the beta of their email based web app, 9cays. The basic premise is that you CC a special email address and then get a plethora of added features for a conversation, such as online archive, RSS feeds, and the ability to add new participants. (see example)

It is somewhat similar to a (almost) zero configuration Yahoo Group.

I’m in agreement that email is in dire need of innovation, and the people behind 9cays are some of the smartest I know. Their service definitely makes group email, and group organisation, easier.

However, I’m not convinced that email itself is the way to progress. I find that I’m using email less and less. My main form of receiving information is via RSS, be that news, information, or the fact that one of my friends needs help to build a house.

In terms of sending information out, I tend to use instant messaging where possible, and SMS if not. Email is something I use for people who haven’t moved on.

At work, one of my teams moved from email, to email lists, to a wiki, to internal blogs. Everyone is now subscribed to each other’s internal blog and we are using it as a collective information store. There is definitely a problem with information management, and as yet no solution. (thingamy notwithstanding)

My thinking is that RSS management needs to become easier. Notification of things that are important to me among hundreds of feeds needs work. I’m not sure what is missing yet, but there is something, and it has to do with priority and context.

9cays are making a start, and in their usual manner have built a large platform behind the scenes. What is visible is merely the tip of the iceberg. I’m watching with interest to see what emerges next.

Recently, I’ve been distracted by reading Paul Graham’s essays as a result of a Tim Bray posting.

My interests have been serious piqued as a result of one of his themes of using Lisp to write web applications. As a higher order language, the theory is that programmers will be more productive and that given the types of programmers who learn Lisp, you can attract better programmers.

It is a very interesting argument. Something that I’ve been giving lots of thought. My interests at the moment are in learning to write native Mac OS X applications. Python fell in my lap as an option mostly due to my background in Miranda and then the more popular (and powerful, useful, free) Haskell.

Part of my motivation behind learning Cocoa programming has been to write a native application that talks to a web based back end. For some tasks, I’m still not convinced that a web browser is the Right Thing, regardless of how much AJAX code you put in place. This is why the Cocoa apps I’ve been writing have typically avoided building their own data layer. One is built on regular expressions and the other on Address Book and iCal.

The bit I’ve been avoiding is writing the back end. Past experiences on this have been in Perl, which is useful, but I just don’t like. I’d rather not have to put $ signs everywhere.

Python seems to have the clean aspect and enough libraries for doing things so I’d been assuming that I’d use Python for the back end too. However, most of my thinking in Python is really derived from my Haskell days, so why not write the back end in Haskell?

I also may have been distracted somewhat by a few other developments such as Ruby on Rails and Django, as even with a thick client in Cocoa talking to a back end, in this day and age, an application really should have a web based version too.

Investigation has also gone into using XUL as it is both web based, cross platform and somewhat richer than AJAX.

All in all, it is a happy time to be in where there is such a wide range of equally valid choices. It now comes down to a question of tradeoffs.

One of the things that I’ve been looking at is web services. So far, I’ve played around with .NET, Java (Axis) and PHP for writing and consuming them, however I wanted to be able to at least access them from Python.

A quick web search didn’t unearth a site which covered everything I was interested in, so a bit more digging was required. The following resources I’ve found useful so far:

• SOAP Web Services from Dive into Python. Covers pretty much everything, including WSDL.
• Python SOAP Libraries, Part 5 from IBM’s developerWorks. Good information on when things go bad. Also has some good references at the end.
• Python Web Services. A container site that includes both the SOAPpy and the ZSI web services code bases for Python.
• README for SOAPpy. Includes installation instructions and code examples

For now, I’m going to try out SOAPpy as it seems simpler. However, ZSI appears to have better support for complex types in WSDL. Complex types being the feature that tends to limit most WSDL tools.

As an example, here is a simple server:

import SOAPpy
import os

def systemInfo():
    return os.uname()

server = SOAPpy.SOAPServer(('localhost', 8080))
server.registerFunction(systemInfo)
server.serve_forever()

The client is as easy as:

>>> import SOAPpy
>>> proxy = SOAPpy.SOAPProxy('http://localhost:8080/')
>>> proxy.systemInfo()[0]
'Darwin'
>>>

os.uname() returns an array of data, which is encoded into XML by the server, and then decoded back into a Python array in the client. On the wire, the actual data looks like:

<SOAP-ENV:Body>
<systemInfoResponse SOAP-ENC:root="1">
<Result SOAP-ENC:arrayType="xsd:string[5]"
	xsi:type="SOAP-ENC:Array">
<item>Darwin</item>
<item>mayumi.local</item>
<item>8.1.0</item>
<item>Darwin Kernel Version 8.1.0:
Tue May 10 18:16:08 PDT 2005;
root:xnu-792.1.5.obj~4/RELEASE_PPC</item>
<item>Power Macintosh</item>
</Result>
</systemInfoResponse>
</SOAP-ENV:Body>

Dive into Python has further information on how to obtain debugging information, as well as an example of performing a Google search.

WSDL is useful in the enterprise space where toolsets do most of the heavy lifting, but it really is too much hard work to write WSDL from scratch. Tim Bray muses about how WSDL could be improved, likening it to SGML for complexity and asking what the XML simplification would be.

Update: Dion Hinchcliffe has provided a good summary of the various alternatives that are in the wings at the moment.

There is a lot happening in this space, even if it is getting confusing. I’ve just been to a seminar where “AJAX” was quoted as the new web service. Amusing given how it is just the result of gluing together existing technologies in an interesting way.