Hi Jon,
good to know that I'm not the only one who is "a bit stressed" with the
current licq :)
With the "least common denominator" I mean that every IM which can handle
multiple protocols only supports what all have in common, leaving out the
things that are important to decide for a specific protocol/program - the
unique features. I really don't think that there is no chance to support as
much of these features as possible (as long as there is no patents-stuff).
Your suggestions and the things you said are exactly what I meant. However,
letting the plugin export functions is a good idea in my eyes.
For icqnd I built an API (onto the original Licq API) which I find not that
bad. Maybe you'll like it too:
Every user is an object (of course), that handles nothing but event
management. Also it has a list of managers which do the real work. Both, the
user and the manager are "signal sources", that means they both can store
functions to call when an event is created/deletet ...
In the end things work the following way:
"IMUserDaemon" is a user. Now a window wants the possibility to receive a
message, it creates a
IMMessageManager (which listens to events of type "message") and adds it to
the IMUserDaemon by doing a
IMUserDaemon->addManager(IMMessageManager);
Now IMUserDaemon goes through his list of events and gives those to the
IMMessageManager it listens to (-> message events). Also IMUserDaemon starts
a call to its connected signal functions (which is another class that does
the general graphics stuff for the user, eg contact list, window management
...).
Next IMMessageManager processes this event further, eg converting it into
the right charset, getting the important information ... and sends a call to
its signal functions (which is the window that created the instance). The
window can then do whatever it wants with the event and then delete it by
calling something like IMUserDaemon->deleteEvent(event);
If the window sends a message it can call
IMMessageManager->sendMessage("bla");
because the message manager is connected to the user it can then do the
work. This API is some way flexible, because you can easily add new
managers, connect as many as you like and connect as many callback functions
as you like and widen the list of capabilities without changing the core.
I don't suggest to take this engine but just wanted to present you what I
find somehow better ...
Regarding a road map I'd really like to have a specific plan made. Let's
make an appointment (somewhere next week) to meet at a chat with everyone
that is interested for a first brain storming session.
Regards,
Joachim
--
GMX Produkte empfehlen und ganz einfach Geld verdienen!
Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Licq-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/licq-devel
