amsn2

[boyska]

WTF?? I was just writing (well, I almost finished the first release) my first plugin (Imitate, I will publish it soon) and I was planning on doing some improvements (most important was a "debug window" similar to the one in gaim (watching the terminal is sooo boring  ).
And now I discover that lots of people will abandon emesene... (sure dx, you won't).
At the moment I won't but I think that the new project is not so bad, but maybe too ambitious: especially the 3 GUIs sounds me "strange"... for example: I'm writing a new plug-in, will it be in gtk, qt or efl? and, most important, if I use the Qt gui, can I use "gtk" plugins?
Seems a little "bloated".

But now is the time for proposal: they are planning multiple guis with the same core... so, how about multiple protocol implementations (long life to emesenelib). This way dx's (and many others', I suppose) work will not be lost, but will return in a different (hopely better) implementation of msn.
This shouldn't be so difficult, but will allow aMsn2(or how we decide to call it) to join ALL the forces and, most important, all the devs.
I think that we (dx, i'm talking to you :-) ) should make this proposal, I believe that aMsn2 will be *happy* of this.

This is a great opportunity we shouldn't waste

[yurek]

ok, it will be great, but dont let us emesene with lot of bugs !!!

==> http://emesene.org/trac/timeline  ( three months unresolved report  !! )

[Tito]

I think that every people who wants great MSN clients on Linux must work together... To make a library !

A perfect library, written in Python, that suports MSNp16 and all his evolutions. With this perfect library, we make different teams : one that works on a gtk version, another on a qt, another on Windows and on Cocoa. All those clients have a perfect MSN protocol... And a perfect implementation in graphical environment.

But aMSN2 developers want to make the whole thing : protocol + gui... One GUI will always works better than others !

[Vincentt]

I think that every people who wants great MSN clients on Linux must work together... To make a library !

A perfect library, written in Python, that suports MSNp16 and all his evolutions. With this perfect library, we make different teams : one that works on a gtk version, another on a qt, another on Windows and on Cocoa. All those clients have a perfect MSN protocol... And a perfect implementation in graphical environment.

But aMSN2 developers want to make the whole thing : protocol + gui... One GUI will always works better than others !

I thought the idea was to create different GUI's on the protocol? i.e. create the "perfect" protocol library and have GUIs built on that?

[kakaroto]

Hi,
I'm KaKaRoTo from aMSN and the one behind the whole aMSN2 project...
I couldn't read all the comments posted here and stay silent, so I decided to register and post a few explanations so people don't get more confused than they already are.
First, thanks for all the guys who are eager about this because aMSN sux :p
Seriously though... you should probably read all my posts in the aMSN forum, especially this one here : http://www.amsn-project.net/forums/viewtopic.php?p=30953#30953
This should give you the answer about the name change.
I just want to let you know that aMSN2 is not the name of the application, it's just a codename, the application will still be called aMSN.
About smartypants who posted this link : http://amsn.sourceforge.net/wiki/tiki-index.php?page=AMSN2+Basics
This is a very old document that had initial thoughts, and it is completely outdated and has absolutely nothing to do with the new design, you shouldn't read that, and you shouldn't take it into consideration... don't read it, or if you did, forget about it... this should help lower the confusion!
@Tito: we'll be using pymsn which already supports MSNP16 (I ported it to MSNP16 when I implemented that in aMSN SVN)... we'll make sure that library is always up to date... we'll also have a different team that takes care of maintaining each of the front ends.

[guillaume]

KaKaRoTo, I still think the name should me changed. Your point of "it's still amsn at its core" is irrelevant, it's pymsn at it's core, and emesene on the frontend, and from what I understand it's the amsn developpers as maintainer of the library (which means port and adapt the code) and EFL frontend.

I underdstand and agree that aMSN as a bigger community than emesene but that's not the point. When Gaim changed name to Pidgin, it didn't affect its fan base. So it shouldn't affect yours as well.
This project is about using different library, language, and contributors. The name change should be reconsidered.

[Fiste788]

eMSN eMSN eMSN!!!!!!!

[mohrtutchy]

I'd like to stop to talk about the name. wariano, jandem and dx know what think emesene community about the name and I'm sure they will talk deeply with other devs about this.
Please, start talking about how we would like the new client to be and join forces to obtain the best MSN client of ever for all platforms.
I tell you a secret... I have a dream: to defeat at all WLM; IMHO this is the way

Blessings

[Tito]

@Tito: we'll be using da mow mow which already supports MSNP16 (I ported it to MSNP16 when I implemented that in aMSN SVN)... we'll make sure that library is always up to date... we'll also have a different team that takes care of maintaining each of the front ends.

Seems nice... Maybe I could switch to aMSN in the future But why does everybody links to damowmow.com?! There's nothing on this website !

[dx]

But why does everybody links to damowmow.com?! There's nothing on this website !

It's a wordfilter. Just don't talk about it, right?

[dx]

New emesene gameplan....

The gtk frontend of amsn2 can be called aemesene

emesene should still live on, it's a need for a smaller client that can work on older computers and the new mini linux laptops.

and something i would like to do, get some money in to the project, so more devs could work fulltime....

The gtk frontend of amsn2 will be called amsn. emesene will stay alive. Both will be written in python, so the performance difference wouldn't be too much.

You can't buy time, unless you can get at least 1000 USD per month for roger and wariano, and something more for jandem since he's from europe. I can't work, so you can't buy my time.

[dx]

ok, it will be great, but dont let us emesene with lot of bugs !!!

==> http://emesene.org/trac/timeline  ( three months unresolved report  !! )

Sorry for that, we just don't have time.

edit Damn, they are mostly duplicates of the same windows bug. Can't they search instead of posting the same thing 800 times?

But now is the time for proposal: they are planning multiple guis with the same core... so, how about multiple protocol implementations (long life to emesenelib). This way dx's (and many others', I suppose) work will not be lost, but will return in a different (hopely better) implementation of msn.

They've already considered this . "gui" talks to "core", which talks to "protocol", which talks the default msn library, and with the corresponding interface, to emesenelib. Of course I won't consider getting emesenelib in amsn2 until it's better than the current one. I've been always against that library (although most of the msn protocol research was done by their developers), so I know many ways to make emesenelib better.

This shouldn't be so difficult, but will allow aMsn2(or how we decide to call it) to join ALL the forces and, most important, all the devs.

[troll] BTW, one of the things i don't like about their default protocol library is that they want to join all forces (?) by denying multiple implementations. Ok, "deny" is perhaps too aggressive. What they say instead is like "writing the ultimate kickass msn library that includes the latest research and infinite flexibility", etc. [/troll]

[dx]

KaKaRoTo, I still think the name should me changed. Your point of "it's still amsn at its core" is irrelevant, it's da mow mow at it's core, and emesene on the frontend, and from what I understand it's the amsn developpers as maintainer of the library (which means port and adapt the code) and EFL frontend.

I underdstand and agree that aMSN as a bigger community than emesene but that's not the point. When Gaim changed name to Pidgin, it didn't affect its fan base. So it shouldn't affect yours as well.
This project is about using different library, language, and contributors. The name change should be reconsidered.

Changing names is too hard to even consider it. Not from the code side, but at least from the website point of view. That is what would hurt me most, leaving this nice emesene.org. There are more reasons of course, but just considering them is a nightmare. The pidgin guys had serious legal reasons to change names.

Also, you've quite misunderstood the amsn2 design. I guess it's not explained elsewhere, so have a graphviz:


The size is approximately the amount of work done by each component. With this I want to emphasize that the protocol library and the core are different, and that "amsn" is the core with all the logic and glue, not the protocol library.

[guillaume]

Oh thanks, much clearer now. anyway good luck with this. "amsn2" have a huge potential.

[boyska]

Also, you've quite misunderstood the amsn2 design. I guess it's not explained elsewhere, so have a graphviz:

The size is approximately the amount of work done by each component. With this I want to emphasize that the protocol library and the core are different, and that "amsn" is the core with all the logic and glue, not the protocol library.

This is the answer I was waiting for. Now everything is much clearer!