Hi! I've been following both forums threads and I could not resist to give my opinion.
Hi lucianolev! I am a very new developer myself (working on the Qt4 frontend) so my answers might not be 100% accurate, but I'll give it a shot anyway.
1. Regarding the name change, I think that coming up with a good name (btw, i like eMSN!) and new fresh website would be great. aMSN2, as stated here, will be not only a COMPLETE rewrite in another language, but also new people working on it. I know that aMSN has gain popularity and it's important as a brand but I think that if marketing stuff is managed correctly, aMSN will not decrease its user base but on the contrary, new adopters will come. As an example, look to Pidgin, it's name change was positive in every aspect (i think).
Also, just imagine a free software messenger client with latest protocol support and multi GUI support, it will be impossible to be ignored! It will be, by far, the most used messenger client at least in GNU/Linux and MacOSX, and it can even rival the official client in Windows! So kararoto, please reconsider this idea, no matter what's the name, if you manage to build a client with the characteristics said before, you got no competition.
Finally, take into account that those how didn't like aMSN for its look & feel, it will be difficult to transmit them that now aMSN does not look the same as before; just think of non-tech people, who don't know what's gtk, python or qt.
I personally don't really care about a name change. It has both positive and negative effects. What I care about is the actual code. The fact that aMSN 2 is a complete rewrite should not mean that the name has to be changed. Either way I am fine with it. The main aMSN developers have already stated their reasons for wanting to keep the aMSN name. If you think those reasons are invalid, be prepared for a lengthy discussion with them. But in the end, does it really matter so much? ...maybe we should make a poll...
2. About the client goals and design in general, I think the most reasonable idea is to concentrate in only one protocol implementation and put all the efforts there. I understand that many people could prefer some toolkit from another but does it really make sense to work on multiple implementations? :shock: IMHO, it's just duplication of work. So please, current emesene and aMSN developers, and everyone who is thinking in creating an live messenger client, work together on improving pymsn!
So, in my opinion the design should be:
Protocol Lib (like an improved pymsn) -> Core & GUI abstraction classes -> Frontends
Also, you should keep the idea of keeping it simple, Live Messenger-like interface and NOT multiprotocol. IMHO, emesene has accomplished this quite right.
As far as I am aware, those are _exactly_ the plans. KaKaRoTo has already stated that eventhough aMSN 2 is going to be very modular, the main developers will only work on making it the best MSN client ever, because their reasoning is that it's better to have a client that implements one protocol (the MSN protocol) perfectly, than it is to have a client that implements many protocols, but not one protocol works like it should, because there are too much protocols to work on.
We also have some teams internally. The core aMSN developers are working on improving pymsn and on the aMSN core, and we have different teams for the front-ends, so everyone can focus on their speciality. The current front-ends already get their data from the core and from a GUI abstraction class.
edit: oops, KaKaRoTo is faster than me in responding to your message :roll:
Show Posts
it's more flashy and it has a really interesting way of theming, I'll give you that.
