Lets say I’m here in Germany on a class about Web Engineering seeing some topic I already saw, and i start thinking on the future implementation of emesenelib.
The codename for this lib until now is E3, why? i don’t know, i just typed “mkdir e3″ so it will stay that way :).
dx edit:
Please, first you should know, that e3 is just an idea, until i get an Internet connection to go back hacking emesene 1.0, so this are just ideas, that wont see the light until emesene 1.0 is released, but is nice to “think before you code” once in a while.
I will start simple, I made a simple diagram of the main architecture it will have, so here it is:
Now, lets explain a little this bag of buzzwords 
The layers are the intended architecture, not all the parts will be developed by the core emesene team, we will just provide the information and API to do it.
Lets go from bottom to top:
* E3 Core: this will be the base library, it will be fully GObject based, asynchronous as far as we can, and maybe thread based.
The signals will be well defined and documented ;), and will be general enough to allow another similar protocols to be implemented [1]. This library will allow the administration of several sessions at the same time, and will allow deferred querys to allow remote frontends (more on this later).
* Interface any_to_object: this layer will allow the layers on top of it, to use common python methods that will be mapped into gobject request signals. This layer is not really necessary, but maybe someone with few knowledge on gobject will find it useful.
* Local API: this two components will allow the frontends to interact with the library using either gobject or DBus (someone said thelepathy? :P).
In the local API, if you are using GObject you can skip this 3 layers, but your application wont be as flexible as it can be (more on this later).
* Remote API: this components will allow remote frontends to interact with the library using common communication methods (XML, Rest, Json, WebServices), this will allow a frontend to run on a different machine than the backend or to make frontends on another languages (also can be accomplished using the DBus API).
* Interface call_to_any: this interface will allow to a python front end to make calls without knowing the underlying “transport” method, this give some flexibility and make a common API available for all methods and allow to introduce new “transport” methods on the future.
* Desktop layer: a frontend using the toolkit of choice (Gtk, Qt, WxPxthon Cocoa, ncurses)
* Web layer: a frontend using a webserver and doing the output on a web format (Html, Html + AJAX/AJAJ, XUL etc.).
Now the crazy stuff part…
with this architecture it will be possible to make things like:
1)
* create a Gtk frontend and use gobject at first to talk to a local E3 core instance.
* someday you want to play a little and decide to change the transport an use for example a Json trasnport and run the E3 instance on some other machine, sounds crazy, but imagine a Nokia S60 runing a Gtk frontend and running the backend on your home machine! ;).
* go to a mac and change the frontend to a cocoa one.
* change it for a Qt frontend while you are on a KDE environment (not recommended :P)
2) create web based emesene with all the fuzzwords you can imagine.
3) change the E3 Core code to handle Jabber instead of MSNP
Well, this are my thoughts on the topic, i hope you enjoyed this post, and i hope that emesene 1.0 see the light soon so we can start to do some weirs stuffs with this ideas.
comments?, questions?
PS: not all of this components will be made at first, as a base, the components that we will code (i hope) are:
* E3 Core
* Interface any_to_gobject
* Local API
* Interface call_to_any
* Gtk frontend
so you will see something like the client we have right now.
the second part will be (I’m just guessing):
* ncurses (dx is interested on this)
* Json Remote API
* maybe a XUL concept implementation (I’m interested on this)
people interested on the other components can implement them..
[1] by someone else
