Category Archives: OSCAR

Stats for Your Open AIM Apps

Posted on by
Reply

In the launch post of Open AIM, I mentioned one of the major improvements was a facelift to the Open AIM Developer Web site. Previously developers had no idea what kind of usage their web app, plugin, client or bot had, unless they built it themselves.

We have corrected this problem. Now client and web app keys will see peak simultaneous users, cumulative sessions, IMs sent and IMs received. Developers of plugins will be able to see stats for peak simultaneous usage and cumulative session count. Developers already with keys in the Open AIM program will start seeing their stats being collected.

By having these stats available any time the owner of the key loads their key management page, they can get a great idea of how users are using the application. Stats are available only to the key owner, and are protected by the identity and password of the key owner. Remember that all keys are now unlimited, so there is no need to recompile applications with a deployment key prior to release. If you already have keys set up for your applications, they have automatically been made unlimited. Here is a screenshot of the key managment page.

Thoughts on the launch and our partners

Posted on by
1

I have gotten about 2.5 hours of sleep over the past 40+ hours. The launch today was a couple months in the making and really there are so many people to thank. So rather than give an “Oscar-like acceptance speech” (pun intended) where the band plays me off the stage, let me just say, “THANK YOU TO EVERYONE WHO WORKED ON GETTING OPEN AIM 2.0 OUT THE DOOR.”

The launch today included two partners that I wanted to take a minute to highlight. We are excited to welcome Seth and the rest of the gang at Meebo into the developer program and we look forward to helping Meebo continue to evolve their client on top of the OSCAR protocol. In the case of eBuddy, we are really happy to add an international partner to the program, especially since we have removed the international clause in the license agreement. eBuddy has been around since 2003 and is based in the Netherlands.

Over the next couple of days I will keep blogging about the program and some other cool things happening around Open AIM at SXSW. Until then, I am going to get a good night sleep for the first time in a few weeks. 🙂

Open AIM 2.0

Posted on by
17

Over two years ago we launched Open AIM by releasing the Windows Software Development Kit that allowed developers to write custom clients, bots and plugins for the Windows AIM client. Since March 2006, we have released SDKs for the Mac, Linux and PocketPC platforms, as well as AIM Web APIs that allowed developers to build AIM onto websites via embeddable widgets, javascript, or XML.

Today we are adding more exciting ways of integrating and leveraging the AIM network. First, we are documenting the AIM protocol, known as OSCAR. Doing this will allow clients built using libraries such as libPurple, and other open source solutions to be enhanced to take advantage of all our protocol. Second, we are simplifying our license agreement, and removing restrictions to allow you to create the applications you and your users want. For example, we will now allow developers to build clients that incorporate other Instant Messaging services, using our SDKs, protocols and libraries. Third, we will allow developers to build compelling mobile applications for all different mobile devices. Fourth, we are removing limitations on developers from building business and enterprise applications. Fifth, AIM Web APIs now support php and AMF3 return formats for easier server and flash integration. Lastly, we are giving our developer website a huge face lift. On the new site, you will find better message boards, easier to navigate documentation and samples, and additional APIs that AOL has to offer. For developers the new website also will include some basic statistics of your application, plugin or bot.

After listening to you, the Open AIM Developer Community, we have also streamlined the process of building applications, plugins and bots. In the past we required developers of custom client applications, plugins and bots to provide a key and fingerprint to get their application authenticated on to the AIM network. We have simplified this by making the fingerprint check optional. In addition, all keys have unlimited usage. For the AIM Web APIs we are removing the requirement for URL referrer checks, which also means fewer hurdles to develop applications and makes for a better user experience.

By further opening up the AIM developer program, we are providing a better experience for all our users whether they are using the flagship Windows AIM client or Meebo in a Firefox browser. At the same time, we are giving developers the opportunity to build applications using best in breed tools and protocol. In order to best support these efforts and ensure that our users receive a high-quality AIM experience, we do require that developers include some specific elements in their applications. However, we have done our best to keep these requirements to a minimum, resulting in greater flexibility for developers and an enhanced AIM experience for their users. We have created a list, from which developers can pick a minimum of 2 items to integrate into their Web AIM or Custom Client application. The list includes:
– displaying advertising
– providing a link to installing the AIM Toolbar
– displaying a users expression/buddy icon as well as providing a link to letting the user set their expression
– displaying a user’s buddy info
– displaying the AIM Startpage

Developers can change out these items as they determine what best suits the needs of their users and their application. We will be adding new options to the list to further increase the flexibility available to the developer, and in the near-term will be adding other beneficial enhancements such as a revenue-share program for displayed advertising.

In conclusion, over the past two years we have seen tremendous growth and excitement over the Open AIM program, and today is just another step in giving developers the best messaging and synchronous communication platform in the world to build on. We know that for our users this change will continue to give them the choice in deciding what is the best AIM experience for them.

AIM Mailbag Part II

Posted on by
2

Last time on AIM Mailbag, we covered versioning, mobile privacy, colorizing screen names and of course the Mac AIM experience (or lack thereof)…and now the mailbag conclusion.

Q: What are some of the new key features being implemented in the upcoming versions of AIM?

A: I always love these questions, but hate answering them because plans are always changing but in addition since this is a public forum, I cannot share all my cards. With that being said, we continue to make important improvements in connectivity both with regards to just signing in through all sorts of network topology as well as for p2p activities like live audio and video. I think you will see improvements in how developers can interact with the client via plugins, which means that users will have cool add ons and extensions to make their AIM experience more fun. Tighter integration with mobile messaging is in the works, as well as handling all different types of mobile data. Like I said, it is not fun being vague, but we are working on some good stuff that will definitely get you excited in using AIM.

Q: Is AIM coming any closer to being inter operable with GTalk?

A: I was asked this same question in Dublin at MashupCamp a few weeks ago, and I will give the same answer. Both of us continue to work on an interop solution and when there is more to share you know you will be able to find it on this blog.

Q: There haven’t been a lot of AIM custom clients. Are you planning to introduce any yourselves?

A: My team is not actively writing any new custom clients, we have AIM Lite, however we have numerous partners who are writing custom clients right now. I am not sure how many full feature AIM clients you will see on Windows, but other platforms are actively being worked upon. Hopefully our partners will be sharing some news real soon.

Here is a quick list of some custom clients:

– AIM

– AIM Lite

– AIM Pro

– Playlinc

– PCD Lounge

Q: My AIM MusicLink is still not working at all it will not show what song i am listening to through iTunes, WMP 11, or Yahoo Music Jukebox.

A: I have to say this one issue has baffled me. Here is what I am guessing is going on, first if you set yourself away and are expecting MusicLink to work, it will listen for your music, but updating the status will not work. Second, if you have installed iTunes in a directory other than the default path (c:program filesitunes) then MusicLink will not work because we need to import the interfaces to access the iTunes API. So if you have iTunes installed in a path other than the default please point it to the default and then all should work. For the other players I have tested against the latest WMP and Yahoo Music Jukebox as well as 10 of my independent testers and we have not been able to reproduce this case unless we are set as away. If you are experiencing problems what would help beyond AIM version and media player version is to make sure you note what your status is (away, idle, invisible, mobile, etc), and if you are signed in on multiple locations.

Q: Who is AIM’s chief software architect?

A: I never comment on personnel here at AOL, but from the Open AIM SDK point of view I am the lead evangelist/dev guy for Open AIM, thus the reason you will see me at conferences, etc.

Q: What do you and people from AIM dev and IM-Host dev team think about alternative clients that use directly OSCAR protocol, not AIMCC?

A: Interesting question. For those who do not know, OSCAR is AIM’s proprietary protocol for communication. OSCAR is very complex and has lots of antiquated and unused things in it, some of which are specific to AOL clients going back to AOL 5.0, and some of which are deprecated. Much like the reason why we did not open up the low layer libraries in AIM known as COOL, we feel like from an elegance and simplicity view, the Web AIM APIs and AIMCC provide a more manageable way of writing clients. In addition, things like libPurple and other libraries do not always interact with the protocol properly. Anyone notice that their buddy lists are not always displayed properly or that Adium does not do file transfer properly? As we evolve the protocol obviously things like Web AIM and AIMCC incorporate the changes immediately, while the unofficial libraries are slow to get these changes if at all.