Skype lowlevel API design for sending chat messages — on the road to too complex?

May 24, 2007

There’s one inconsistency in Skype’s lowlevel API design. On a basic level, the Skype API is text-based (like many other protocols on the Internet) – you send and receive text messages. And on some platforms (Linux, Mac), that’s all you have for now. On Windows there are some higher level options (COM), but I want to talk about the text API, particularly in regard to posting chat messages. (And not only talk here but of course also with the chat API engineers.)

So… let’s imagine a common scenario with chats and API. Let’s say you’re building some communication interface that needs to send chat messages to other Skype users, and you will use the regular Skype client API. (And yes, I know the most optimal way to do this would be to eliminate the Skype client from the loop altogether and use some webservice. But today I want to limit myself to client API protocol/messaging design.)

How you would do this would be to simply tell the API, “send message A to user B”. And on older versions of the API, there is a command that does exactly this.

Syntax
    MESSAGE <target> <text>

So… all you need to do is to send the command “MESSAGE B A” in the above case to the API, and forget about it.

Strangely, this command has been marked as “deprecated” and is said to be replaced by the newer CHATMESSAGE command. With this command, you need to first create the chat, and only then you can send a message to it.

So, let’s compare the sequences of posting message A to user B. In the lists below, –> means “send command to Skype” and <– means “receive command from Skype”.

With the old MESSAGE command:

• –> MESSAGE A B

With the new CHATMESSAGE command:

• –> CHAT CREATE A
• <– CHAT <chat_id> STATUS DIALOG
• (capture <chat_id> in application)
• –> CHATMESSAGE <chat_id> B

So… there is an extra step inbetween. And I have posted before about how there is confusion between versions about synchronous vs asynchronous call responses, and it isn’t trivial at all to capture this chat_id and maintain chat state consistency (so that you’d know when chat has been created, wouldn’t send messages to nonexistent chats and otherwise be a well-behaving corporate API citizen :) ).

The good news here is that although the MESSAGE command is deprecated, it actually still functions and works as a macro that does both the CHAT CREATE and CHATMESSAGE parts. This is really good, and I would argue that in the case of dialogs this is all that’s often really needed for posting. So maybe we could keep this simple behaviour and not require developers to deal with complicated chat ID maintenance if all they need to do is simple posting.