You've probably at least seen:

http://florianjensen.com/2008/01/17/aol-adopting-xmpp-aka-jabber/

So I played with this a little yesterday .. very cool!  I certainly hope that AOL does indeed go through with this and embrace XMPP!  Based off my experience with OSCAR and XMPP, they -could- accomplish everything they're currently doing with OSCAR with XMPP.  Do they want to?  Is this simply a gateway to their AIM and ICQ services?  Who knows, but it's good to see!  I would imagine AOL has already seen how excited folk are about this, probably by their poor test server getting suddenly wailed on.  I can only hope they won't decide this is a bad idea.  The thing is, people like to use AIM and ICQ.  People like to use XMPP.  Why do they have to be at odds?  AOL's take on how chatting should work could bring wonderful improvements to XMPP overall.  I think Google's joining the fray did a lot of good for XMPP in general in terms of XEPs that came about because of it and such.  And people like me wouldn't be spending so much time building transports or multi-protocol clients if we didn't at some level like the services we were connecting to.  For example, I don't hate AIM.  I simply like a lot of protocols and don't want to run 8 different chat clients on my desktop.  I also think the OSCAR protocol is interesting, as are the other protocols, so I wanted to learn more about them.  Does that mean I'm out to make XMPP overtake AIM?  Hell no.  To be frank, it would be a happy day to me if the transports were no longer necessary, if people on AOL's servers could chat with people on my own server and on jabber.org's server and on lots of others without having to figure out the protocols.  Does this mean no one would try to dissect the protocols anymore?  Probably not.  Part of the drive of that is learning and understanding.  It doesn't have to be about trying to circumvent.

Imagine if AOL decided they really liked XMPP overall and ditched OSCAR though.  That would hose old clients.  But what if they released a new client that spoke XMPP while keeping their old servers going?  Furthermore, what if that client could point at other servers than AOLs.  Now AOL has a nice client or two out there for any XMPP clients to use.  That's kinda cool!  There's plenty of great XMPP servers out there at this point.  The client choices in general are a little lacking.  Spark, of which I'm in charge of nowadays, is pretty, it's cross platform, but it's a beast.  Java is not necessarily great in terms of small memory footprint.  Coccinella has a lot of cool features but it's Tcl/Tk and I've never liked the "feel" of Tcl/Tk.  Google Talk, there's not a version for my OS, so what good does it do me.  iChat...  nothing personal Apple but I've never liked it.  I can't put my finger on why really.  It's also hard to explain why I don't use Psi for everyday use.  I love it for development.  Nothing is better IMO.  But for some reason it didn't feel simple enough to be something I want to use as a regular client.  Adium X and Pidgin?  It's the primary client I use but it lacks a lot of XMPP functionality (though it's definitely improving on that front)  All of these are good clients, and have good followings, but there's still a lot of room for other 'entries' to come into the mix.  Nothing seems to "do it" for everyone yet.  Of course, who knows if that will ever happen.  But seriously AOL, I'd love to see you throw your hat into the mix!

Now what about MSN and Yahoo and others?  Yahoo, I could see them possibly embracing XMPP.  Hell they bought Zimbra and Zimbra's suite has XMPP capabilities nowadays, so they have some bought expertise there.  MSN on the other hand, they sell a product (LCS? OCS?  whatever it is) that may be a good drive -not- to embrace XMPP.  I don't know much about OCS or LCS though.

Overall though, this kind of reminds me of e-mail.  Everyone can have their own implementations of email services and such, that doesn't mean we can't all speak the same language!  AOL, I hope you take all this attention as a compliment!  I think we're all proud and pleased to see you express an interest in XMPP and maybe join the family!!!

Well, as it turns out, I was missing an entire method of handling buddy icons in the AIM/ICQ world.  There's also an ability to attach a "hey, I have an icon, LOVE ME!" flag to your outgoing messages.  Visa versa, you are supposed to pay attention to said flags from other people.  Soooooo, soon there will be better icon support for PyAIM and PyICQ.  I need to figure out how I want to handle this though.  Not a long post for now, just wanted to mention that I'm thinking through this.

So, apparantly I am going to have to do a lot of misc extra work to get the updated oscar.py back into Twisted Words.  That's fine, it just means it'll be a while longer before I do so.  I'm apparantly supposed to set up some unit tests, write up more documentation, and explain what all has changed from the previous version.  While I'm more of the opinion that it would be helpful to at least have a more functionality one there . . . if that's the rules they want to follow that's fine with me.

So it shouldn't be too hard to throw together at least some unit tests.  Perhaps a simple log in, send a message, receive it on the other end, and close the connection for starters.  Obviously there's a lot I could test over time, but that's probably a good place to start.  I would have to emulate the server's responses 'locally'.  (Twisted tests are done for a local file system socket that's supposed to pretend to be the actual network connection)

As for documentation, the only balk I have there is that I have to learn their documentation style.  Yet another thing I need to devote some time to.  It looks like it's one of those "document internal to the code" type deals, plus I could throw in some extra bonus documentation that's not within the code.  (IE, is not technical looking API documentation, but rather is "how to" type documentation)  I've put together a couple of extra examples that I think I'll submit as well.  Should be a party.

The only problem I have with all of this is Twisted seems to be a moving target lately.  It seems like we keep having to do things like "If Twisted > XXX version, import this, if Twisted > YYY but < XXX, import this, else import this" type stuff.  Hopefully that will settle down over time.  That's part of why I'd like to drop Twisted 1.* support.  It would remove most of the needs for such checks.

Anyway, back to the incorporation.  The "things that have changed since the original version" is going to be interesting.  A -LOT- has changed.  =)  I'll have to ask what level of detail they want.  Guess I'll get to that when I get to it.  My more pressing need is keeping my PyAIM and PyICQ users happy.