I want to take a break from writing about code and spend a bit of time on blue-sky stuff, our approach to standards, and the technologies we want to adopt. I’ll try to keep the jargon to a minimum.
At Huddle we work to a tightly controlled schedule, from a prioritised list of business requirements. A typical business goal might be to improve our calendar, for example, or to make our notification emails easier to read.
Alongside these business goals, we have an overall technical vision. Nobody else in the company knows about it yet, because it’s written on a Rizla packet next to my workstation, but it says Bet on Openness; Build Trust.
I originally started writing about the first part of that warm and fluffy dictum: about how Huddle is building trust with its customers, but it sounded like marketing swill and I had to stop before I made myself poorly – you’ll just have to trust me when I say we’re trustworthy – the first part is far more interesting to write about as a geek.
Huddle.Net is quickly gaining a reputation for being one of the best collaboration tools available on the internet. We want to go a step further than our competitors, and build the best possible *platform* for collaboration, where Huddle.Net is only one client for that platform.
Traditionally, we’ve built new functionality into the website and worried about how we expose it to end-clients later. Now that we’ve managed to get our house in order with respect to extensible security and sane layering for business logic, we want to do things the other way round. In the future, we should build functionality into our API and consume it from our website. This has tangible benefits for scaling our application, because it is trivial to place our service layer on a separate server from the presentation layer, but it has more interesting benefits for our customers.
Firstly, if we’re using our API to offer our service, then you can be certain that we’re looking after it properly. We’ve recently had a couple of glitches in the API, because it’s been a second-class citizen. That will have to change: our APIs are every bit as business critical as our site. More so, even.
Secondly, it will force us to design our APIs in terms of real-world usage. It’s easy to knock out an unusable ball of mud when you’re designing a web service, unless you actually have to write a client for it.
Thirdly, it will mean that if you are paying us to host X Gb of files, and for Y minutes of teleconferencing, then you can consume those quotas from whatever Rube Goldberg contraption you can cook up. It means that cool little apps like AlertThingy will be able to get all the data they need, because ALL our functionality will be exposed. It means that you are free to use Huddle’s services in whatever ways you can dream up, and we’ll help you do so because we’re geeks and get excited about that kind of thing.
The business case for this is clear: we expect that a *very* significant portion of our traffic will come from third parties in the next two years. If we can charge for workspaces and file storage, just as we do now, then there is NO downside to allowing other people to provide services on top of Huddle – more consumers == more subscriptions.
What does that mean in concrete terms?
Okies. So I’m expressly forbidden from guaranteeing anything to anybody, particularly when it comes to the product roadmap: if I say that the Earth is in orbit around the sun, or that we’re going to revamp our calendar, then you *can’t hold me to it* mmmkay? I’m just a programmer. That said, there are some things that we know we want to do. Eventually. No promises.
1) OAuth and OpenID
I’m not a fan of Facebook Connect, because I think it … er… *spits* … in the face of the web community; it’s an atavistic throwback to the bad old days of AOL and MSN, when everyone was building walled gardens, and we were all going to have internet-enabled refrigerators .
We currently work with a few OpenSocial providers, and OAuth their lingua franca for identity provision. If we properly support OAuth then we can drop support for our legacy SOAP API – the one you guys don’t want to know about – and move all the functionality to the RESTful API – the one that you guys can play with.
OAuth will likely be the auth protocol that we use when our website talks to our API, and by using three-legged OAuth, you can plug your own website into our API and build services on top of Huddle in a secure way.
OpenID is of less immediate use to us, but I really like the user experience of Windows CardSpace, and would love to be an early adopter for that framework. Identity management is a key part of building enterprise software, and we need to make it easy for external partners to plug their existing identity data into our application.
We were one of the launch partners for LinkedIn’s OS offering, and we’re putting the final touches on a couple of other projects that are still under wraps. OpenSocial is going to be an important part of our platform moving forward, and is accounting for a large chunk of our traffic.
We’re considering becoming an OpenSocial provider – it wouldn’t be too hard if we get our API layer right, because there’s a fairly simple mapping from our API to the standard OS APIs – this would mean, amongst other things, that you could write your own OpenSocial gadgets and have them display on the Huddle dashboard.
We’re keen to support a proper widget system, because we get a lot of requests for functionality that we simply don’t have time to implement – if we open up the dashboard as an OpenSocial container then you can write whatever funky widgets you like and build them into the site, with full access to your data. There’re obvious security considerations here, but we’ll burn those bridges when we come to them.
3) Synchronisation and open formats
The other major format on our list is iCalendar . I’ve recently been looking at our iCal handler, which we inherited, and looking at the iCal specification to see what we can do better. It turns out that we can do a LOT of things better. In the next few weeks, the development team will stop scheduling meetings in Outlook, and schedule them in Huddle instead. This means developers are free to use Google Calendar, or 30boxes, or iCal to view their tasks and meetings from Huddle. It also means that we’ll have to implement the missing functionality we need ASAP.
We’d like to do bidirectional sync, so that if you add a new meeting into your Google Calendar, then Huddle will pick it up and add it to your Huddle Calendar – I mean, why the hell not? Properly supporting iCal will make it much easier for you to access your Huddle schedule on an iPhone, or on your corporate intranet.
If someone in Huddle creates a new task and assigns it to you, you should be able to view and work with that task in Outlook, or RememberTheMilk or in HiveMinder. This is what we mean when we say “Bet on Openness”.