On Fri, Mar 31, 2006 at 04:32:13PM +0200, QnD [Joachim Staib] wrote: > good to know that I'm not the only one who is "a bit stressed" with the > current licq :)
Well, I have been stressing over it for awhile, but just didnt have
the motivation to do to it all by myself.
> 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).
Ahh, I see. Yes, it is surprising how many of the popular IM clients
do not support some of the nice features of a protocol. I'm not sure
why, but I don't see it as a very hard limitation. Just takes a bit of
time to understand the protocol and implement new features that don't
exist in any other clones and are undocumented.
> 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.
Hmmm.. did you by chance mean to say "not a good idea"?
Traditionally most APIs will expect a few functions from the plugin,
and Licq currently does that. We only require the functions for plugin
management. All signals and events are sent through a pipe. The
benefits of this are:
* A common interface for all events. Only knowledge of the parameters
passed in the Signal/Event are needed.
* A clearly divided meaning of Signal and Event.
Now the bad point:
* All Signals and Events will require the same amount of memory, even
if it is not needed.
* If a new function is added to a single protocol, the current
Signal/Event classes may be deemed insufficient and the API has to
be modified to accomodate this one function.
* Complexity on the plugin developer. They have to watch what event
comes, and then based on the parameters, call a function. With an
API that calls exported functions, they don't have to worry about
calling their own functions based on the parameters.
Obviously I can think of more bad points than good points :)
Another idea is that when the plugin is loaded, it can tell the daemon
what functions it will export for what the daemon can do. For example,
if the daemon can receive messages (which of course it can), the plugin
would tell the daemon, "Hey, when I get a message, please let me konw
at msn_recv_msg please! Thank you." Basically acting as a callback.
> Every user is an object (of course), that handles nothing but event
So the user object is currently ICQUser. I'd like to rename it to a
more generic name LicqUser.
> 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:
So LicqUser would be in control of calling all the managers that would
then relay onto the plugin? It sounds a bit complicated to work in the
daemon, but perhaps I have a misunderstanding of what it is doing on
the overall view. Perhaps, if I could see some more examples or code.
Do you have any for the icqnd plugin?
For exmaple, when a user changes status, sends a message, how would it
handle these cases?
> 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 ...
Hmm, sounds interesting... like I said above, I'd be interested in
some sample code if you already have some.
> 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.
Well, this Tuesday at 2000 GMT+9 I will be home if you want to meet on
#Licq to discuss this in more details. I've been pretty busy lately,
so e-mail is the best way to contact me, but I will have some times I
can be on #Licq without any distractions.
Jon
--
________________________________________________________
Jon Keating ICQ: 16325723
[EMAIL PROTECTED] MSN: [EMAIL PROTECTED]
http://www.licq.org GPG: 2290A71F
http://www.thejon.org HOME: Minamiashigara, Japan
pgpwBIKPP9HLV.pgp
Description: PGP signature
