First of all, the best cover ever: http://www.youtube.com/watch?v=FjeMDvCdrtc
No comments. It reminds me Anton Maiden. Don’t you know Anton Maiden? Shame on you.
If you are not a geek, you dont need to continue reading below 🙂
As in AC/DC song: It’s a long way if you wanna… do things in the right way.
libcurl is a great library which provides ways to open and manage sockets and http requests in a simple form. I was using it to help libmsn development, but as I intend to keep libmsn as independent as possible, I’ve decided to use openssl sockets instead of libcurl. The best part is now the code is prepared to handle non-block sockets, even when using ssl connections, which is, in my opinion, a big requirement to not block the whole library (as we can have many sockets alive at a time) when we are requesting something through SOAP, for example.
The code is broken and I’m working to fix it, but I must admit it is a very boring work.
Sunny Sunday: a good day to develop OIM (Offline Instant Messages) to libmsn.
Yes, now libmsn has full OIM support (receiving, sending and deleting).
I could write here all my feelings about the protocol, SOAP and XML parsing, but I’m trying to avoid this kind of discussion because I can discover very soon that it was really needed to do something I don’t know yet (btw, xml text inside another xml text node?? I think there are too many ways to not need to do that. I hope I’m wrong, really!).
Next step is try to finish Address Book management (add groups, add user, move user to group..). All these operations are made now through SOAP requests (oh my..!!). Wish me luck.
some people asked me about posts involving music, because computing is a very boring subject. I agree with them, music is much more interesting than computing, so there goes she wolf (by megadeth) video played by me. I know it’s not equal to the original version, but this is how I like to play it =)
The sound quality is horrible because I used a standard PC microphone. I intend to improve this recording process next time. Probably you don’t know this song yet, but I can ensure you it is very cool. Enjoy.
yesterday my friend boiko encouraged me to contact Mark Howe, the original libmsn developer. I told him about the changes I made in libmsn, and I asked him his thoughts about forking libmsn. He told me it’s been 2 years the development is stopped, and if I want to maintain the code and revive the project I’m welcome. So, there is no need to fork libmsn so far.
Now it is time to face the worst part, which is code the library. 🙂
Today I dropped all the qt code I’ve been using to help on xml parsing. Instead of qt I’m using xmlParser, which is a tiny library I found when I was googling xml related subjects.
Probably next week I’ll have some news about the current development status.
yesterday I decided to start playing with a capture card I have, but I faced a big problem: my PC is a laptop and the card is PCI bus. Since I don’t have PCI bus in my laptop, I couldn’t use it. The fastest solution was use my sister’s PC, which is a desktop one. This situation made me think about developing something to share the hardware through the network. For example: if NFS could export /dev directory, I would export it in my sister’s PC and mount it at /mnt/dev, and then access /mnt/dev/video0 in a native way. The problem is that video0 isn’t a normal file, it is a char device, and NFS does not support char device exports. If we think a little bit more, we will realize that the main problem consists on ioctl() function, which its use is very common on char devices. This function allows us communication with devices in a simple way by passing an ioctl type and some data or a pointer (most of times a pointer to structs) to the function. Each type of ioctl has different data types and sizes, so if we want to do it through the network, we need to map all the types and associate them to a fixed size (considering we cannot pass a raw pointer through the network). Anyway, it is possible to get the data size with _IOC_SIZE() function, for example:
int size = _IOC_SIZE(VIDIOC_G_MPEGCOMP);
where VIDIOC_G_MPEGCOMP is the ioctl type, and size will be the size of the data VIDIOC_G_MPEGCOMP requires.
I don’t know if I’ll have time and know-how to do the full development, so if you are able to do that and enjoy coding these crazy things, fell free to do it, and if I decide to start developing that I’ll post the progress here.
If you have more ideas or if I’m terrible wrong on my explanation, let me know.
Here I am again to announce my latest progress on porting libmsn to MSNP15.
The file transfer is finally working (just receiving through server). I’ve tested receiving files from some different clients, like kopete, pidgin, amsn, Mercury (thanks to AsTrOdYuM) and the official MSN client. Up to now it seems OK. Next step is try to allow direct connection. One interesting thing is that the switchboard limits the transfer speed to 3k (average), and if you try to send many files at a time, the bandwidth will be shared between them. That’s why kopete file transfer is very slow. Kopete does not support direct connection. aMSN does support and pidgin does not even try to start direct connection negotiation.
I need to clean up the code yet. Many parts of the old MSN file transfer protocol are still in the code. I didn’t remove them to not break the building process.
During the tests I’ve found an aMSN bug. If you try to send many files at a time, probably the first one will be successfully completed and the other ones will fail. I thought it could be my fault, but the same does not occur in any other client, only in aMSN. Anyway aMSN has a good way to transfer files, testing the connectivity before inviting the other user. It tries direct connection first, if no response is received, then it sends through server. Probably when I start to change the file transfer code to send files too, I’ll use this approach.