Alright, I've tried AIM, ICQ, Y!, MSN, Trillian, GAIM and Odigo, and have yet to find one that really has everything I want, so it got me thinking about making my own. I've got a decent programming background, but would definitly have to do some research to finish this project. It would be open source so you could either customize it yourself, or even help a little.
Anyways, here are some basic ideas I have...feel free to comment on the feasability of these ideas
Client side:
Java-based for easy porting to other platforms (Win32/Linux/Mac out of the box) - Good idea? C++ would be the obvious alternative, but what arguments does it have going for it vs. Java that are strong enough to combat the ability to port it easily. It would be offered in compiled code so that you could run it on the three platforms without a JVM. A web-based fully featured client should be easy to produce as well.
All settings stored in XML files - This would allow you to easily backup your settings, or even change them yourself.
XML Skinning ability - Very similar to what is found in trillian. I like the way trillian does skins.
Support for multiple IM protocols (more on this under the server side description)
Server side:
Here is where this program would differ heavily from other options available. This is also where I'm not sure about the practicality of this project. While you could just have it only use existing chat platforms to begin with, that instantly puts a limit on the capabilities of the program. Plus you can fall victim to AOL deciding to block you, etc.
That is why I would like to have my own protocol and servers. I of course can't run my own network of servers, as I don't have anywhere near the financial backing that would require however. That is why I came up with the idea of a kind of local server. Here is the basic idea:
You would have one local server (say if anandtech wanted to run one - im.anandtech.com). You would connect to that server using your own im name, say Scootin159. Your screenname would then be "scootin159@im.anandtech.com". Say you wanted to talk with someone on a different server however, maybe hardocp has one. Your friend would then have the screenname "steve@im.hardocp.com". Now don't worry about the ugly names here, they would be fully "renameable" at the client level. Anyways, when you go to talk to "steve@im.hardocp.com", your message would be sent to im.anandtech.com which would then do a DNS lookup on "im.hardocp.com", find the IP#, and then send the message to im.hardocp.com, where it would be sent to steve. The whole system is much like what you have with SMTP.
As far as supporting other IM services, I think this should be done @ the server level...or do you think it should be done @ the client level? At the server level you would just have the server maintain your connections to the proper IM service. This would make people more motivated to switch over to the new IM service, raising the popularity of this service, while they could still maintain their current services.
All commands that the server supports would be made available publicly as well, so people could even develop their own IM clients. It would a kind of open protocol.
What are your thoughts on this idea?
Anyways, here are some basic ideas I have...feel free to comment on the feasability of these ideas
Client side:
Java-based for easy porting to other platforms (Win32/Linux/Mac out of the box) - Good idea? C++ would be the obvious alternative, but what arguments does it have going for it vs. Java that are strong enough to combat the ability to port it easily. It would be offered in compiled code so that you could run it on the three platforms without a JVM. A web-based fully featured client should be easy to produce as well.
All settings stored in XML files - This would allow you to easily backup your settings, or even change them yourself.
XML Skinning ability - Very similar to what is found in trillian. I like the way trillian does skins.
Support for multiple IM protocols (more on this under the server side description)
Server side:
Here is where this program would differ heavily from other options available. This is also where I'm not sure about the practicality of this project. While you could just have it only use existing chat platforms to begin with, that instantly puts a limit on the capabilities of the program. Plus you can fall victim to AOL deciding to block you, etc.
That is why I would like to have my own protocol and servers. I of course can't run my own network of servers, as I don't have anywhere near the financial backing that would require however. That is why I came up with the idea of a kind of local server. Here is the basic idea:
You would have one local server (say if anandtech wanted to run one - im.anandtech.com). You would connect to that server using your own im name, say Scootin159. Your screenname would then be "scootin159@im.anandtech.com". Say you wanted to talk with someone on a different server however, maybe hardocp has one. Your friend would then have the screenname "steve@im.hardocp.com". Now don't worry about the ugly names here, they would be fully "renameable" at the client level. Anyways, when you go to talk to "steve@im.hardocp.com", your message would be sent to im.anandtech.com which would then do a DNS lookup on "im.hardocp.com", find the IP#, and then send the message to im.hardocp.com, where it would be sent to steve. The whole system is much like what you have with SMTP.
As far as supporting other IM services, I think this should be done @ the server level...or do you think it should be done @ the client level? At the server level you would just have the server maintain your connections to the proper IM service. This would make people more motivated to switch over to the new IM service, raising the popularity of this service, while they could still maintain their current services.
All commands that the server supports would be made available publicly as well, so people could even develop their own IM clients. It would a kind of open protocol.
What are your thoughts on this idea?
Facebook
Twitter