Over the holidays I spent a lot of time working on node-ncurses and improving it. I pushed the changes I made to the github repo awhile ago for those interested.

I’ve also recently pushed a change to node-imap which makes the fetch() mechanism async and a stream. By streaming, I mostly mean it uses event emitters with familiar event names to transfer fetched messages and their data. This should fix the reported out-of-memory issues. Message headers are still buffered internally though, since they need to be processed and turned into an object/hash.

With those changes out of the way, I’m hoping to now spend some time on node-oscar again.

For the past week or more I have been struggling to find out why AOL was disconnecting me after making a connection to a second BOS server for additional services. The main BOS server would disconnect without any notice (connection reset by peer) when sending it any packets after connecting to and setting an additional connection.

This morning I was again looking into the issue and I was looking at a wireshark dump and it hit me: sequence numbers! I thought for sure AOL wouldn’t be strict about their sequence numbers, but after some testing it appears that is quite true. What was happening was I was sharing the FLAP sequence number among all connections, so by the time I had completed the sequence of commands on the additional connection, the shared sequence number had been increased quite a bit. So by the time I send another FLAP packet on the first/main connection, AOL decided it lost some packets judging by the difference between the last sequence number it received and the one contained in the current FLAP packet.

What I can’t understand is why they don’t send a FLAP error packet that would have easily highlighted the actual problem instead of forcefully severing the connection.

So a word to the wise: make sequence numbers connection-specific and (obviously) increment them only by 1 for each FLAP packet sent.

Lastly, as a quick update: I’ve got most of the basic functionality down and am now working on chat, file transfer, and direct connections.

After finishing the majority of the main features my node.js imap module, I’ve been looking for another protocol to implement. SMTP was already started on by someone else and POP3 isn’t worth implementing IMHO. Then I started browsing the node.js module wiki page and saw people that are working on an XMPP module. So that gave me the idea of creating an implementation of OSCAR (the protocol for AIM/ICQ) for node.js.

I spent all of tonight and this morning gathering protocol information and coding and I’m now ~25% or so done. The documentation available on some parts of the protocol are completely missing (especially info about family/service versions).

Some time back I started writing an imap module for node.js. I had most of the usual functionality finished, but I got stuck on trying to come up with a quick and easy way to parse the result of a BODYSTRUCTURE command. At the time I was hoping there’d be some giant regex that would just work for this, but I couldn’t find one.

So tonight I sat down and wrote my own BODYSTRUCTURE parser using the format detailed in the imap4rev1 RFC and it has worked with every BODYSTRUCTURE result I’ve thrown at it. Now I need to go back and refactor the rest of the module to make the whole asynchronous handling a little saner.

So today I spent some time writing up an irc bot (using node-irc) that lets you do node.js api lookups from an irc channel.

There are some small kludges because some parts of the api are treated specially. I’ve also had to make some modifications in a couple places in node.js’s api.markdown so that it can be parsed a little better.

I’ll probably be publishing the bot to github sometime soon, but I’d like to add some currently missing features yet before that happens.