[prev in list] [next in list] [prev in thread] [next in thread] 

List:       licq-devel
Subject:    [Licq-devel] shutdown issue and api suggestions
From:       Joachim Staib <camael () gmx ! net>
Date:       2005-09-12 16:51:56
Message-ID: 1126543917.1505.24.camel () camael ! qnd ! com
[Download RAW message or body]

hi,
since icqnd supports loading / unloading of protocol plugins there's a
problem I haven't found a solution for yet. When MSN is loaded and icqnd
is shut down the licq backend remains running (I think MSN isn't
shutting down), so licq has to be killed in order to have it terminated.
When shutting down the qt-gui everything works fine. Does one have to
unregister all plugins so licq shuts down? I took a look into the qt-gui
source and couldn't find any command for this. Or is the termination of
all plugins when shutting down the qt-gui hardcoded into the licq
backend? 

another thing are some api suggestions. Protocol plugins should be as
independent as possible from the licq backend. To archieve this I
suggest the following things (in case they're not planed already). 

1. plugin defined states: because possible states differ from proto to
proto every plugin should be able to provide a kind of array defining
the possible states. For icq this would be something like
"Online" -> ICQ_STATUS_ONLINE
"Away" -> ICQ_STATUS_AWAY
"Not Available" -> ICQ_STATUS_NA
"Occupied" -> ICQ_STATUS_OCCUPIED
...

for MSN this array then contains
"Online" -> ICQ_STATUS_ONLINE
"Offline" -> ICQ_STATUS_OFFLINE
...
"On the Phone" -> ICQ_STATUS_OCCUPIED
...

GUI's should then read this array to get the correct icon / status
description and (what's most important) the number of all possible
states. At the moment (as I understand this) the possible states are
directly coded into the GUI.

2. plugin defined info fields: the same as with the states -> every
plugin has different user info fields. Maybe one could define ulong's
for every information category defining the supported info fields, which
would look like
plugin()->GetInfoFields(FIELD_WORK);
the result could be a ulong storing the fields in a bitwise order, like
infoGeneralField = INFO_FIRSTNAME | INFO_LASTNAME | INFO_AGE |
INFO_BIRTHDAY | INFO_BIRTHMONTH ...
where INFO_FIRSTNAME would be 1<<0, INFO_LASTNAME = 1<<1 and so on. It
would be neccessary to find out which information is available for the
most popular protocols and to make a list. This makes protos not
completely independant from the GUI since there could be protos having
completely other info fields, but it would require only little changes
to include them then. In fact, GUI's should only use this list to build
info windows / tooltips ...

3. emulation of unsupported features: the only thing I'm thinking about
at the moment is sending contacts to MSN users. While icq internally
supports this feature the licq backend could fake this feature for the
MSN protocol and sends a message containing the neccessary information
instead of really using a (not existing) feature.  


... just my ideas while making the GUI and not having the muse to spam
the code with "if (PPID == LICQ_PPID)" ... lines :)
If you (main developers) work at other things at the moment I'd like to
start implementing the suggestions into the licq backend (as far as they
meet your plans) and send a patch then.

Regards
	Joachim



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Licq-devel mailing list
Licq-devel@licq.org
https://lists.sourceforge.net/lists/listinfo/licq-devel
[prev in list] [next in list] [prev in thread] [next in thread]