Since Jim has posted Episode 24 of the Podcast at Delphi.org and explained that we’re making an open source Twitter client I thought I would write a quick post about some of the design decisions which we’re already facing. In Particular about the decisions around the internal class that will handle communication with the Twitter API.
Background
As a little background we’re aiming to create an open source Twitter client using Delphi, involving the wider community in as much as possible. We realise that there are several million existing clients for virtually every platform, language and environment ever built but we would like to do this because:
- There aren’t currently any Libraries or Applications built with Delphi (afaik).
- This will hopefully provide discussion and learning resources for the Podcast and for the community.
- It will be fun for those involved!
The aim of the client isn’t to be the most fully functional or visual-effects laden available but to produce a solid, stable and lightweight native client. We simply won’t have the developer time or resources available to build the next Tweetdeck. Most of the most widely used desktop twitter applications such as my own personal favourite TWhirl are built on the Adobe Air which means they usually consume vast quantities of RAM, an issue which I clearly wanted to avoid as I’m fed up with a my Twitter client consuming 100Mb+ of RAM.
The Twitter API
The Twitter API is a simple API which attempts to adhere to the Representational State Transfer (REST) principles. At it’s most basic state, you can get the latest public timeline of tweets through an Http GET request to: http://twitter.com/statuses/public_timeline.xml
Library within a Project Design Decisions
As part of the overall Twitter Client design we wanted to have a Delphi Twitter API client library which a delphi developer could extract and potentially use on a different project if they so wished.
One of the other design considerations is that our library needed to be reserved about making API calls. This is because the Twitter API is rate limited and usually only allows 100 requests per 60 minute time period but this can dynamically change according to the load that Twitter is under (for example, Heavy traffic and infrastructure problems during WWDC 08 meant it was reduced to 60 requests). We must also not forget that many users have more than one application accessing the API so we can’t assume that all 100 requests are solely for our own use meaning that we must be as restrained with our API calls as we can.
When we began pulling together this library I initially felt that there were two different routes which we could take:
- A One to One direct representation of the Twitter API Methods. i.e. For each call in the REST API Documentation, there should be an equivalently named function taking the same parameters with a minimally structured result object.
- A Higher level and more object orientated “Delphi-ified” Abstraction of this. i.e. Break away from the naming of the API functions into higher level requests and objects that might potentially make several low level API calls for one of the high level functions.
The Second option is the authentic Delphi way of doing this and would lead to the creation of a library which would draw on the strengths of Delphi. The advantage of the One to One Direct Representation of the API it means that almost any developer who is familiar with the Twitter API can read the documentation and see exactly what he is calling and how he is calling it without having to learn the idiosyncrasies of a client library on top of understanding the API. The bare-bones API version however would need some higher level handling and objects building on top of it before it could be really useful to our Twitter client but would require careful data cache’ing to avoid utilising too many API requests.
This leaves a whole host of questions to be resolved:
- How modular do you make the class before you begin to erode the flexibility of your library?
- How much code are you prepared to add to make the class generic enough to be used in other projects but without compromising on the purpose for which it was built (this project)?
These questions are not unique to Twitter or REST API libraries in general; Most Delphi components abstract a specified resource in a similar way to this, some choose the minimal API reflection technique, others provide a full high level object orientated interface.
I suspect that the optimal solution to ours lies somewhere in the middle but I would love to get some opinions on how you would design it? Have any of you worked with similar REST clients and have guidance or tips to pass on? Are their any similar remote libraries which you have used which were so easy to use that you would recommend we learn from them?
I am a Delphi Developer, .NET and Web Developer and General Geek. I am an enthusiastic advocate of hobbyist development and in particular tools which allow for hobbyist development. Please have a good look around and enjoy anything that you find useful on this site. 
Why don’t you get the best of both worlds?
Make a TAsCloseAsPossibleToTheTwitterAPI
Then make a TDelphiTwitter that contains an aggregated instance of the TAsCloseAsPossible…. The TDelphiTwitter will expose easier to use “Delphi-ified” methods, but will call the TAsCloseAsPossible to communicate with the server.
That way, if you are a twitter genius, you can just instantiate the TAsCloseAsPossible and use it directly if you like.
Excellent write up Jamie!
@David Novo: That is probably the ideal solution and it looks as if that might be the way we are heading anyway. The only problem with that, I guess, Is that you have to add the polishing touches to two classes but it would probably be worth it.
@Jim: Thanks!
@Jamie and @David: This is what I’ve been thinking about in general terms, I can’t just put my head together to get t o the specifics, AAAAAARGH
I pretty sure that the code will be more will be far most instructing the twitter itself
http://www.youtube.com/watch?v=PN2HAroA12w
I agree with David 100%. DISQlite3, for example, took this approach – a very thin wrapper around the native sqlite api’s, then the ‘Delphi way’ object-oriented full-featured structure. I personally have used both of these wrappers for different purposes. I think the best libraries provide both types of layers…
@Gustavo: It’ll click together eventually ..
@rap: Apparently the UK isn’t able to access that video but I suspect I know which video you might be linking to!
@katoa: Thanks for your input, I’m a fan of these types of dual wrappers myself anyway.
@Jamie: Yes it will, and probably with the JSON lib I’ve sent you by mail. Let’s hope that gets us closer
http://www.progdigy.com/?page_id=6
Hi Jamie,
I’ve worked with Delphi for 13 years. Maybe in somewhat of a tunnel-vision way. Primarily in a D7 and below – Win 32 environment, but working with a different group, and with a different type of App intrigues me enough that I’d like to offer some time to your Twitter project – if you’re interested. I have also done some Asp.Net and tinkered with REST via Rails. Shoot me an email if you’re interested.
Thanks,
– I’m @CodeWhiz
Scott – We met earlier today via Twitter
I’ve finally released a VERY EARLY version of the Dweetta Lib, my own version of a Twitter lib and simple client for Delphi/FreePascal.
You can find the Assembla page here: http://www.assembla.com/spaces/Dweetta
I hope the community gives a hand.