Interview: BeMSN Developers (BME). Feb 15, 2004 23:27 UTC, by Jess Tipton, Contributing Journalist From the Alien Application Star Base department... BeMSN, MSN Messenger for BeOS Takes on a new name and new crew TBJ takes some time to speak with the new BeOS MSN Messenger Client development team. Why did you decide to make an MSN Messenger clone? BME: BME is not really an MSN Messenger "clone". We want to write a client that provides many of the features of the official client, but in a Be-like way. We hope to add some innovative features to the interface that you just won't be able to live without. As for why we decided to do this, we all have different reasons, so we'll answer individually: Daniel (Taki): I first started BeMSN almost two years ago. Back then the only reason I booted my machine in Windows instead of BeOS was that in BeOS I couldn't talk with my friends, mostly with my girlfriend, over MSN. So I asked, how hard could it be to write it myself? I was surprised to find very detailed documentation about the MSN Protocol on the web. So I started making attempts to login to the service. That is how I got started. At the time, I didn't understand segment violations and many other things. I made progress in between school semesters. After a year and a half I had a working BeMSN, so I uploaded it to BeBits. After the last update of BeMSN, I received an e-mail from Tim and Simon about their plans for making a better client that supported the latest protocol and many other enhancements. Now there is a team working to get the best MSN client out there for the BeOS community. Simon (tb100): Just over a year ago, I wanted to learn C++ and contribute something to the BeOS community. I needed a project that was approachable as a first-time C++ coder, yet that would offer something really useful to users. At that time, there were no decent, free MSN clients on BeOS. I started one and called it si-mSN (a clever combination of "sim" and "MSN", hence the very confusing hyphen and capitalization :P). You can see some old news about the project at http://si-msn.port5.com. When BeMSN appeared, it actually worked (I didn't have any networking code written), so I gave up with my client. The protocol switch on October 15th that stopped BeMSN working for a bit was the spark for me to pick up the project again, after receiving an e-mail from Tim asking if we could collaborate on a new MSN client. When we saw BeMSN updated again, we decided to ask Daniel to join us. Tim (Mik): One of the reasons I still boot to Windows is to use MSN - that need will be reduced when we have a reliable MSN Messenger client around. Also Simon and I were discussing a new kind of open-source development model at BeGroovy and later via e-mail. This open-source development model should be open to the whole community, with lots of user feedback; after all, they are the people you write your software for. We wanted to test some of our ideas by writing a small app and see how it turned out. When there were no updates to BeMSN (and it stopped working) I mailed Simon to try to test our ideas with the development of a new MSN client. After BeMSN was updated and started working again, we (Simon and I) didn't know what to do - continue the project and duplicate work, or stop and see if our ideas would be implemented in BeMSN. We agreed we should mail Daniel to ask if he wanted to cooperate with us...and luckily he did! Why not port something like Gaim that can do all the major IM protocols? BME: Although ports can be useful, a good native app is always better as it can be written to be much more consistent with the OS itself. Also we want to use many features of the Be API - messaging, multi-threading, etc. If we wanted to write Linux apps, we would code in Linux! We also have many of our own ideas for the interface, and want to throw this open to the community too (any good ideas...tell us!). Starting from scratch gives a lot more freedom in this respect as we can control the project right from the design stage. Also doing a port is less fun, and often less rewarding, than designing everything about the app from the design stage. A multi-protocol messenger like Gaim is tough to do well even in concept as all the major protocols provide different feature sets. There are two basic approaches to creating a multi-protocol messenger - 1) pick a small subset of functionality (sending messages) and have a consistent interface, or 2) implement as much as possible for each protocol, leading to an inconsistent UI and confusion for the user ("How come I can send a file to friend@msn.com and not to friend@jabber.com?"). Neither of those are particularly clean solutions, so for now Be-messeng-er will be MSN only. What are you aiming to have functional in the first public release? BME: For Version 1, we have planned: - All basic MSN functions (contact list, sending messages) - Contact list groups - File transfer - Emoticons - User pictures - Hotmail integration - Stability - Some really nice UI features that you won't be able to live without There may be a "first public release" before version 1 which will not include all of this functionality. We may also release small test releases and proof-of-concept apps to get feedback on user interface issues. Any idea on how long until a first release is made? BME: No, not really! It's hard to say, we are all busy people. There may be some more "interim" releases of BeMSN before our UI is ready. Don't be expecting Version 1 of BME as described above for at least 6 months, maybe more. Since there will be a merge between BeMSN & Be-messeng-er who had the most progress and will much of the old code be kept? Or will you be looking at starting fresh because of a larger project scope? Be-messeng-er itself was started from scratch. It grew originally from the ideas behind si-mSN, but the code in that was not good at all (as it was Simon's first C++ app), so it serves more as a source of ideas and inspiration than a source of really usable code. BeMSN has a lot more code, and some of this will be reused in Be-messeng-er. Tim is currently looking at the overall structure of the code to see which bits can be reused. BME is being designed from scratch because of our goal to make the best client possible (from both a user perspective and an architecture perspective), but a lot of the network protocol code from BeMSN will probably be directly copied and pasted. Most of the UI code in BME will be brand new. Do you plan to get as close as possible to the real clients features with user pictures, voice chat, & file transfers? BME: As far as we can, yes. User pictures and file transfer are definitely on the list. Voice chat would be nice to have, but that would require finding some documentation of the protocol, or an open source client that can connect to MSN voice chats. How do you feel about the limits your clients will face due to OS sub-systems, such as lack of web cam capabilities? The only OS-level thing missing for all the MSN functionality is web cam support. Web cam support for BME is going to be difficult anyway due to a lack of knowledge about the protocol used. If there is an open source program that can take part in a web cam conversation with MSN contacts, then we'd like to know about it. However, even if BeOS supported all web cams available, support would probably not make it into version 1 of BME. Will you try to provide web cam capabilities for those who are using capture cards compatible with Be? BME: We can't pledge to support any sort of audio or video chat due to our lack of knowledge about the protocol used, but it is certainly an area we are interested in. Capture card input appears in BeOS as a "Video In Node". If anyone ever writes a USB web cam driver, that would be the natural way to access a web cam too. That means that if we want to add support for any sort of video input, it would all be done in the same way. In other words we wouldn't have to write a work around for capture cards while we wait for proper web cam drivers; we would simply access video in nodes which would give us support for capture cards now, and web cam support in the future if drivers are written. We're not exactly sure how BeOS handles this - but we think web cams and capture cards work the same way, just as Media Nodes (they are both types of video input, after all). If we add the necessary code to support audio/video chats from the protocol point of view, then both capture cards and BeOS-supported web cams should work. This almost certainly won't make it into the first version though. Do you plan on adding any special features that are for Be to Be clients, such as if file transfer is added proper attribute handling? BME: We hadn't thought about the file attribute handling - but it is a good idea! It's quite hard to find out what client your contact is using, but there are some ways of doing that. We don't want to end up doing what MSNPlus on windows does (that allows multiple fonts in messages, but anyone not using MSNPlus just sees ugly control characters in the message - it doesn't check if the person at the other end is using MSNPlus too). We would only add any Be to Be functionality if we could be sure when the contact at the other end was using BME too. In your pre-interview e-mail you stated you wanted to work off user feedback and develop a client as free as possible from the annoying things the real client has. Does this leave you with a sense of possible frustration as you can only innovate as far as the Microsoft's client allows? BME: We are only really limited by the protocol itself. As far as that goes, it supports all the functionality we can think of. A lot of useful features (like emoticon support) can be implemented completely in the client, and there is a lot of room for innovation there. We noticed a lot of the chat window in the official client is wasted space, there is duplicated information, and lots of completely empty areas. We have the freedom to redesign that. Tool tips in the contact list often don't provide you with the information you want - we think we can improve that, too. One final example: changing your screen name in the official client is quite a long procedure - in BME it will be the work of a single click. We're sure there are many more little improvements (or even major changes) that would improve the experience of using MSN. We can think of loads - but we're sure you've got some more. That was the idea of using a lot of user feedback right from the design stage. Get thinking what *you* would like to see in an IM client, then come over to our forums and tell us! We'll also have questions to ask users as we develop, and maybe some mockups to request feedback on. All of this will take place on the public forums. We hope that the project will attract some active, committed users who can really pay a key part in the development. You might even get a mention in the About box! Do you have a web site & bug tracking system? BME: BME is going to be open source, and is hosted at Sourceforge at the moment. We will probably use their bug tracking system. You can find our home page at bme.sourceforge.net. We are still in the process of getting the site set up. When we have it all ready and we want your suggestions and ideas to start flooding in, we'll get a news item posted at TBJ and other BeOS sites. In September 2003 Microsoft stated that it's expensive to run an IM network and for cost and security reasons October 15th would be a cut off date where unlicensed & unofficial clients would be shut out of their networks. What insight do you have on the real client that will help you stay on top of the changes Microsoft implements over time to keep "Unofficial" and unlicensed clients off their IM networks? Initially, Microsoft were claiming to be quite co-operative: http://www.microsoft.com/presspass/features/1999/08-18messenger.asp BME: What actually happened on October15th is that MSN stopped any clients connecting with protocol versions 7 or lower. That included most of the 3rd party clients, as well as old "official" Microsoft clients. Providing your client now uses a newer protocol (which is more secure, due to the SSL authentication process), the client will not be banned. There are some fine folks on the net who have done a great job of documenting the protocol, which now covers up to MSNP9 quite well. The "Windows Messenger" shipped in Windows XP only uses MSNP8, so it seems a safe bet that protocol will remain supported by the MSN servers for quite a while. We are targeting MSNP9, which is the protocol used in the current MSN Messenger 6. From the server's side of things, it is very hard to tell if you are an official client or an unofficial client. Provided you abide by the same protocol as the official client, as far as the server is concerned you are the official client. Are you afraid that if a foreign client is noticed on their networks, legal action may be taken against you? BME: I have seen e-mail correspondence from Microsoft where they seem to suggest they no longer "support" 3rd party clients on their network, but that they don't really care about them either. As mentioned above, it is really difficult to detect what clients are in use on the network. Also, there are much bigger and more well-known 3rd party clients about (Miranda, Trillian, Gaim), and Microsoft hasn't taken any action against them. Gaim was downloaded nearly 30,000 times in the last week, whereas we probably won't have that many downloads in a year. Trillian makes money from their product, whereas ours will be free and open source. Overall, legal action against us seems extremely unlikely at the moment. Well Trillian is supposed to have a license but we won't go there. Thanks for your time. BME should shape up to be a very significant piece of software for the Be community. Not only is the developer attitude focused on bringing a native application to the Be OS, but they are focused on the users experience, something many developers seem to overlook or simply ignore these days. I look forward to watching their progress and encourage every one to get involved. We need to all work together to keep our OS and software base alive. The BME project can be found at http://bme.sourceforge.net.