icqlib-dev

Re: [icqlib-dev] RFC: My tasks for icqlib

[Bill S. <we...@ri...>]

On Thu, 14 Dec 2000, Ben Reser wrote:

> That sounds good to me.  However, something I'd like to get done is
> sending and receiving contact lists.  Question is, are there any
> opinions about how it should be done considering Bill's list of items
> he's going to be doing?

Hey Ben,

A friend of mine was asking about this too.  Seems to be a popular
feature, though I've never used it!

Go ahead and implement it however you want - I'll make my changes after
you code it, if necessary.  You'll probably just want to add a new
callback for it, and provide a new function to send one...

Once the whole event thing goes in, then we'll need a new
ICQ_CONTACT_LIST_EVENT or something like that, but I have no idea when
that will be finished.

Bill

Re: [icqlib-dev] RFC: My tasks for icqlib

[Ben R. <be...@re...>]

On Thu, Dec 14, 2000 at 12:40:55AM -0500, Bill Soudan wrote:
> Okay, I've sat down and come up with a big list of things I've been
> planning on doing with icqlib, and I'm going to start actually doing these
> soon.  Michael was a big push in the right direction here, since some of
> these interface changes are long overdue.  I wanted to run these by
> everyone, especially the whole event proposal.

Bill,

That sounds good to me.  However, something I'd like to get done is sending and
receiving contact lists.  Question is, are there any opinions about how it
should be done considering Bill's list of items he's going to be doing?

-- 
Ben Reser <be...@re...>
http://ben.reser.org

Maslow's Maxim:  If the only tool you have is a hammer,
you treat everything like a nail.

[icqlib-dev] Re: RFC: My tasks for icqlib

[Michael H. <mw...@ca...>]

On Thu, 14 Dec 2000, Bill Soudan wrote:

> Okay, I've sat down and come up with a big list of things I've been
> planning on doing with icqlib, and I'm going to start actually doing these
> soon.  Michael was a big push in the right direction here, since some of
> these interface changes are long overdue.  I wanted to run these by
> everyone, especially the whole event proposal.
> 
> I cc'ed you Michael because I'd be very interested in any feedback you
> have on the interface changes, especially the event proposal that's going
> to follow.

Cheers, although I seem to have made it onto icqlib-dev anyway...

I've made a few comments in waht follows.

> * Smallish outstanding tasks:
> 
> 1. Clean up file session interface and chat session interface.  This
> consists of moving file data/file status to a their own callbacks,
> probably icq_FileSessionEvent and icq_ChatSessionEvent.  These would work
> similar to icq_RequestNotify.  Port the chat session code to the same
> interface as file sessions.

This certainly seems to be a good idea - RequestNotify seems to be
uncomfortably overloaded at present.

> 3. Finish the away message code.  Away messages come back when the
> destination contact is away and has an away message set, in the TCP ack
> packet.  I'll pass this back as a new field in icq_RequestNotify, since as
> far as the protocol is concerned it's really part of a request.  So you'll
> receive something back like:
> 
>    icq_RequestNotify(icqlink, ICQ_NOTIFY_USER_STATUS, status of
>       destination contact, 0);

Can I just point out that occasionally passing something other than the
length of data in the length argument to RequestNotify strikes me as, erm,
odd?

>    icq_RequestNotify(icqlink, ICQ_NOTIFY_AWAY_MESSAGE, length,
>       away_message);
> 
> I also need to add the code to set away messages, and send them back with
> the ack, so we can have away messages, too.

> 5. TCP socket create/delete notification.  The tcp implementation
> dynamically opens and closes sockets as the library is used.  I don't make
> these sockets public anywhere, you just need to call icq_Main on a regular
> basis which handles the select logic internally.  This was always kind of
> a hack :(  This bit me when I was working on file transfer, because the
> data rate can be very high, and kicq was only calling icq_Main every 0.1
> seconds...

It would be nice to be able to have one's app sat in a select loop, so
that you could write roughly:

while 1:
    r,w,e = select.select(readers,writers,[])
    ...

as opposed to:

while 1:
    r,w,e = select.select(my_readers,my_writers,[],0.01)
    link.Main()
    ...

I don't know, I'd just prefer this in some situations.

> I'd like to add some method so the library client can keep track of the
> sockets and install/remove some sort of socket notification mechanism,
> e.g.g QSocketNotifier in kicq.  I'm undecided on how to do this yet- my
> initial thoughts are to use 2 new callbacks:  icq_SocketOpened(int
> socket), icq_SocketClosed(int socket).  Any better ideas?

Sounds sufficient to me.

> 6. Move private members from icqlink into a private structure.  This will
> get rid of some of the cruft from icqlink that library clients don't need
> to see.  Examples:
> 
>   void *icq_TCPLinks;
>   void *icq_ChatSessions;
>   void *icq_FileSessions;

Good idea.

> * Medium tasks:
> 
> 7. Document icqlib.  I'm undecided on whether to do this now, or wait
> until we implement the icq event interface.  Michael has a good start here
> already.  Planning on placing the documentation in-line and generating the
> documentation using doxygen.

I'd say get something done now.  The current interface will still be there
even if an event interface gets added, won't it?

> * And the big one:
> 
> 8. Implement the icq event interface I talked about long long ago.  I
> started the code over the summer, it's probably about 70% done for the tcp
> messages.  My plan is to implement it internally first, and then expose
> the interface so that library clients can use it too.
> 
> I'll send the entire event interface proposal seperately.  I'd really like
> to see comments on it, if you think it's a good idea/bad idea, etc.
> Especially you Denis, though I think you had liked it, and if you think it
> will work for UDP too.

I haven't gone through that in detail yet.

> And, can we bump the icqlib version number up? :)

I'm a bit surprised this hasn't happened yet, as there's been an
incompatible API change since 1.0.0 was released (the extra arg to
icq_Init).

Cheers,
M.

[icqlib-dev] RFC: event interface proposal

[Bill S. <we...@ri...>]

* ICQLIB 'icq_Event' Proposal

The main goal of this proposed interface is to provide a more
object-oriented approach to sending and receiving ICQ 'events', by:

1) reducing the number of callback functions that the library client must
install to receive events by consolidating them into a single
icq_EventReceived callback

2) provide a single entry point to send events, along with supporting
event structures (one structure for each event).

3) Make the asynchronous event status messages, currently passed through
icq_RequestNotify, consistent across all event types and transports (UDP
and TCP).  I think the UDP code is good here, though I haven't taken a
thorough look lately, but I know my TCP code needs work, the file and
chat requests in particular.

* Event interface

There will be three main functions here:

1) all current receive event callbacks compressed into one:

    void (*icq_EventReceived)(ICQLINK *link, icq_Event *event);

2) sending events would be through single call

    long icq_SendEvent(ICQLINK *link, icq_Event *event, transport);

    transport - ICQ_SEND_THRUSERVER, ICQ_SEND_DIRECT, ICQ_SEND_BESTWAY

    returns a (long) event_id back to the program, used to match
       events to the asynchronous event status notifications from
       icq_EventNotify

3) asynchronous event status like sent, acked, failed, etc:

    void (*icq_EventNotify)(ICQLINK *link, DWORD event_id, int result,
      unsigned int length, void *data);

* icq_EventReceived

Some example code:

   MainWindow::OnEventReceived(ICQLINK *link, icq_Event *event) {

      switch(event->type) {
         case ICQ_MESSAGE_EVENT:
            MessageReceived((icq_MessageEvent *)event);
         case ICQ_URL_EVENT:
            MessageReceived((icq_URLEvent *)event);
         default:
            printf("message received from %d with unknown type!\n",
               event->uin);
     }

     icq_EventDelete(event);

   }

Fairly straightforward.  Program receives messages and passes them along
based on their type.

* icq_SendEvent

Some example code:

    // send someone a message
    icq_MessageEvent *pevent = icq_InitMessageEvent();
    (icq_Event *)pevent->uin = destination_uin;
    pevent->message = message;
    icq_SendEvent(icqlink, pevent, ICQ_SEND_BESTWAY);

    // send a url through the server
    icq_URLEvent *pevent = icq_InitURLEvent();
    (icq Event *)pevent->uin = destination_uin;
    pevent->message = message;
    pevent->url = url;
    icq_SendEvent(icqlink, pevent, ICQ_SEND_THRUSERVER);

This is definitely a little more work, but if you think about the
client's implementation, they could use the icq_Event structure right
away and it would probably actually SAVE code.  ex. kicq could keep an
icq_Event member in its message class, and use the variables in the
directly instead of having class member variables in its classes.

I don't like the casting but I don't know how else to do struct
'inheritance' in c?  Any better way?  See the end of this proposal for my
structures...

I'm also tossing around the idea of leaving the old methods in for
convenience.  So someone could still use icq_SendMessage(icqlink, uin,
message) for instance.  It will be up to the coder to decide which
interface to use - the functional interface will probably work better for
quick and dirty programs and scripts, while the event structure would
probably work better for larger, object-oriented applications because
they can use them directly.

* icq_EventNotify

   /* The request has been completed successfully. */
   #define ICQ_NOTIFY_SUCCESS        0

   /* The request has failed */
   #define ICQ_NOTIFY_FAILED         1

   /* A direct connection has been initiated to remote user */
   #define ICQ_NOTIFY_CONNECTING     2

   /* A direct connection has been established to remote user */
   #define ICQ_NOTIFY_CONNECTED      3

   /* A packet has been transmitted.  Note in the case of UDP, this may
    * be sent back by library more than once due to packet loss! */
   #define ICQ_NOTIFY_SENT           4

   /* The remote side has acknowledged the packet we sent */
   #define ICQ_NOTIFY_ACK            5

   TODO: add notification constants for proxy connecting, if used, e.g.
   ICQ_NOTIFY_PROXY_CONNECTING, ICQ_NOTIFY_PROXY_CONNECTED,
   ICQ_NOTIFY_PROXY_INITIALIZED, etc...

A few example timelines:

client:  icq_SendEvent(icqlink, login_event, ICQ_SEND_BESTWAY)==1;
library: 1 ICQ_NOTIFY_SENT
           ... (time goes by while waiting for ack)
         1 ICQ_NOTIFY_ACK - once received from the server
         1 ICQ_NOTIFY_SUCCESS - this event has been transmitted
                                successfully

  * NOTE: ICQ_NOTIFY_SUCCESS doesn't mean the LOGIN proceduce completed
    successfully, only that the request was transmitted successfully.
    You must wait for the ICQ_EVENT_LOGIN_SUCCESS event to be received from the
    server.

client:  icq_SendEvent(icqlink, message_event, ICQ_SEND_BESTWAY)==2;
library: 2 ICQ_NOTIFY_CONNECTING
           ... (delay during connect)
         2 ICQ_NOTIFY_CONNECTED
         2 ICQ_NOTIFY_SENT
           ... (delay waiting for ack)
         2 ICQ_NOTIFY_ACK
         2 ICQ_NOTIFY_SUCCESS

client:  icq_SendEvent(icqlink, message_event, ICQ_SEND_THRUSERVER)==3;
library: 3 ICQ_NOTIFY_SENT
           ... (packet lost, server never acks)
         3 ICQ_NOTIFY_SENT
           ...
         3 ICQ_NOTIFY_ACK
         3 ICQ_NOTIFY_SUCCESS

client:  icq_SendEvent(icqlink, search_event, ICQ_SEND_BESTWAY)==4;
library: 4 ICQ_NOTIFY_SENT
           ...
         4 ICQ_NOTIFY_ACK
         4 ICQ_NOTIFY_SUCCESS

... icq_UserFoundEvents come in on icq_EventReceived for a while
... icq_SearchDoneEvents comes in

* old callbacks -> new events and some example structures

// icq_Logged - ICQ_EVENT_LOGIN_SUCCESS

// icq_Disconnected - ICQ_EVENT_DISCONNECTED

// icq_RecvMessage - ICQ_EVENT_MESSAGE

typedef struct icq_MessageEvent_s {

   struct icq_Event header;

   const char *message;

} icq_MessageEvent;

// icq_RecvURL - ICQ_EVENT_URL

typedef struct icq_URLEvent_s {

   struct icq_Event header;

   const char *message;
   const char *url;

} icq_MessageEvent;

// icq_RecvWebPager - ICQ_EVENT_WEBPAGER

typedef struct icq_WebPagerEvent_s {

   struct icq_Event header;

   const char *nick;
   const char *email;
   const char *message;

} icq_WebPagerEvent;

// icq_RecvMailExpress - ICQ_EVENT_MAIL_EXPRESS

typedef struct icq_MailExpressEvent_s {

   struct icq_Event header;

   const char *nick;
   const char *email;
   const char *message;

} icq_MailExpressEvent;

// icq_RecvChatReq - ICQ_EVENT_CHAT_REQUEST

typedef struct icq_ChatRequestEvent_s {

   struct icq_Event header;

   const char *message;

} icq_ChatRequestEvent;

// icq_RecvFileReq - ICQ_EVENT_FILE_REQUEST

typedef struct icq_FileRequestEvent_s {

   struct icq_Event header;

   const char *message;
   const char *filename;
   unsigned long filesize;

} icq_FileRequestEvent;

// icq_RecvAdded - ICQ_EVENT_ADDED

typedef struct icq_AddedEvent_s {

   struct icq_Event header;

   const char *nick;
   const char *first_name;
   const char *last_name;
   const Char *email;

} icq_AddedEvent;

// icq_RecvAuthReq - ICQ_EVENT_AUTHORIZE_REQUEST

typedef struct icq_AuthorizeRequestEvent_s {

   struct icq_Event header;

   const char *nick;
   const char *first_name;
   const char *last_name;
   const char *email;
   const char *message;

} icq_AuthorizeRequestEvent_s;

// icq_UserFound - ICQ_EVENT_USER_FOUND

typedef struct icq_UserFoundEvent_s {

   struct icq_Event header;

   unsigned long uin;
   const char *nick;
   const char *first_name;
   const char *last_name;
   const char *email;
   char authorize_flag;

} icq_UserFoundEvent;

// icq_SearchDone - ICQ_EVENT_SEARCH_DONE

// icq_UserOnline - ICQ_EVENT_USER_ONLINE

typedef struct icq_UserOnlineEvent_s {

   struct icq_Event header;

   unsigned long status;
   unsigned long ip;
   int port;
   unsigned long real_ip;
   char tcp_flag;

} icq_UserOnlineEvent;

// icq_UserOffilne - ICQ_EVENT_USER_OFFLINE

// icq_InfoReply - ICQ_EVENT_INFO_REPLY

typedef struct icq_InfoReplyEvent_s {

   unsigned long uin;
   const char *nick;
   const char *first_name;
   const char *last_name;
   const char *email;
   char authorize_flag;

} icq_InfoReplyEvent;

// icq_ExtInfoReply - ICQ_EVENT_EXTENDED_INFO_REPLY

typedef struct icq_ExtendedInfoReply_s {

   unsigned long uin;
   int country_code;
   char country_stat;
   const char *city;
   const char *state;
   int age;
   char gender;
   const char *phone;
   const char *hp; // ??
   const char *about;

} icq_ExtendedInfoReply;

// icq_WrongPassword - ICQ_EVENT_INVALID_PASSWORD

// icq_InvalidUIN - ICQ_EVENT_INVALID_UIN

// icq_SrvAck - this would be passed back through icq_RequestNotify

[icqlib-dev] RFC: My tasks for icqlib

[Bill S. <we...@ri...>]

Okay, I've sat down and come up with a big list of things I've been
planning on doing with icqlib, and I'm going to start actually doing these
soon.  Michael was a big push in the right direction here, since some of
these interface changes are long overdue.  I wanted to run these by
everyone, especially the whole event proposal.

I cc'ed you Michael because I'd be very interested in any feedback you
have on the interface changes, especially the event proposal that's going
to follow.

* Smallish outstanding tasks:

1. Clean up file session interface and chat session interface.  This
consists of moving file data/file status to a their own callbacks,
probably icq_FileSessionEvent and icq_ChatSessionEvent.  These would work
similar to icq_RequestNotify.  Port the chat session code to the same
interface as file sessions.

2. Finish the cancel tcp messages that I'm missing.  Mostly for chat and
file transfer - e.g. I don't think icqlib understands chat reject
messages. yet.

3. Finish the away message code.  Away messages come back when the
destination contact is away and has an away message set, in the TCP ack
packet.  I'll pass this back as a new field in icq_RequestNotify, since as
far as the protocol is concerned it's really part of a request.  So you'll
receive something back like:

   icq_RequestNotify(icqlink, ICQ_NOTIFY_USER_STATUS, status of
      destination contact, 0);
   icq_RequestNotify(icqlink, ICQ_NOTIFY_AWAY_MESSAGE, length,
      away_message);

I also need to add the code to set away messages, and send them back with
the ack, so we can have away messages, too.

4. I'd like to fix the crash with larger TCP messages, but I can't
reproduce it.  Is anyone out there still having this problem?

5. TCP socket create/delete notification.  The tcp implementation
dynamically opens and closes sockets as the library is used.  I don't make
these sockets public anywhere, you just need to call icq_Main on a regular
basis which handles the select logic internally.  This was always kind of
a hack :(  This bit me when I was working on file transfer, because the
data rate can be very high, and kicq was only calling icq_Main every 0.1
seconds...

I'd like to add some method so the library client can keep track of the
sockets and install/remove some sort of socket notification mechanism,
e.g.g QSocketNotifier in kicq.  I'm undecided on how to do this yet- my
initial thoughts are to use 2 new callbacks:  icq_SocketOpened(int
socket), icq_SocketClosed(int socket).  Any better ideas?

6. Move private members from icqlink into a private structure.  This will
get rid of some of the cruft from icqlink that library clients don't need
to see.  Examples:

  void *icq_TCPLinks;
  void *icq_ChatSessions;
  void *icq_FileSessions;

* Medium tasks:

7. Document icqlib.  I'm undecided on whether to do this now, or wait
until we implement the icq event interface.  Michael has a good start here
already.  Planning on placing the documentation in-line and generating the
documentation using doxygen.

* And the big one:

8. Implement the icq event interface I talked about long long ago.  I
started the code over the summer, it's probably about 70% done for the tcp
messages.  My plan is to implement it internally first, and then expose
the interface so that library clients can use it too.

I'll send the entire event interface proposal seperately.  I'd really like
to see comments on it, if you think it's a good idea/bad idea, etc.
Especially you Denis, though I think you had liked it, and if you think it
will work for UDP too.

And, can we bump the icqlib version number up? :)

Thanks,
Bill

[icqlib-dev] Latest changes

[Denis V. D. <de...@nu...>]

2000-12-06  Denis V. Dmitrienko  <de...@nu...>

	* icqlib/queue.c, icqlib/stdpackets.h, icqlib/tcp.h, icqlib/tcphandle.c:
	Handling for mass TCP messages has been added based on patch by
	Konstantin Klyagin <ko...@ko...>

-- 
Denis V. Dmitrienko | E-mail: de...@nu... | ICQ#: 5538614
Home page: http://denix.org
History became legend... Legend became myth.
And some things that should not have been forgotten ...were lost.

[icqlib-dev] Latest commits

[Bill S. <we...@ri...>]

2000-12-03  Bill Soudan  <so...@kd...>

        * icqlib/queue.c: fixed compilation with gcc-2.96

        * icqlib/tcplink.c: fixed bug #105068

[icqlib-dev] windows version

[Mark S. <mse...@gr...>]

I am playing around with creating a windows port of libicq.
I have taken the existing code with the windows source modifications
and have gotten it to compile and link with a simple application.
This is based on the library code that Guillaume Rosanis created. 
From there I've created a very simple application that will allow a
user to logon and it works!!!  Before I spend a lot of time trying
to figure out the callback and timing mechanism for using with Win32,
has anyone done this already????

	--Mark Seidner--

[icqlib-dev] Latest changes

[Denis V. D. <de...@nu...>]

Hi.

Please pay attention, latest changes are incompatible! icq_Init()'s
parameters list has been changed a little bit.


2000-11-02  Denis V. Dmitrienko  <de...@nu...>

	* icqlib/icq.h.in, icqlib/icqlib.c, icqlib/udp.c:
	Ability to disable TCP protocol has been added.

	* icqlib/udphandle.c: Do not ack unhandled protocol version.

-- 
Denis V. Dmitrienko | E-mail: de...@nu... | ICQ#: 5538614
Home page: http://denix.org
History became legend... Legend became myth.
And some things that should not have been forgotten ...were lost.

[icqlib-dev] ["Rafael R. Sevilla" <dido@pacific.net.ph>] programming with icqlib?

[Denis V. D. <de...@nu...>]

Hi.

I just tired answering people that we don't have any documentation
yet... ;)

-- 
Denis V. Dmitrienko | E-mail: de...@nu... | ICQ#: 5538614
Home page: http://denix.org
History became legend... Legend became myth.
And some things that should not have been forgotten ...were lost.


Date: Thu, 7 Sep 2000 16:15:23 +0800 (PHT)
From: "Rafael R. Sevilla" <di...@pa...>
To: de...@nu...
Subject: programming with icqlib?

I just have to ask...is there a document floating around there that
describes the icqlib 1.0.0 API?  Well, I *could* write a small app I'm
starting to develop without it, but it would take much longer.  And I'd
probably be more than happy to document my efforts so such a document
would exist if it doesn't already.  If one doesn't, could you give me a
few hints on how to start using icqlib just to get me rolling, and simple
example programs that use icqlib, if any (kicq doesn't count; it's far too
complex for this!). Thank you very much for any help!

--
Rafael R. Sevilla <di...@pa...>         +63 (2)   4342217
ICSM-F Development Team, UP Diliman		+63 (917) 4458925
PGP Key available at http://home.pacific.net.ph/~dido/dido.pgp

[icqlib-dev] [Marcus Jacob <rossi@aiXplosive.de>] Porting ICQLIB to BeOS

[Denis V. D. <de...@nu...>]

Subject: Porting ICQLIB to BeOS
From: Marcus Jacob <ro...@ai...>
Date: Tue, 22 Aug 2000 17:31:52 +0200
To: de...@nu...

Denis,

I've done a quick port of icqlib to BeOS, however I'm facing some minor 
problems. First I get undefined symbols when libtool tries to link the shared 
library (these appear in icqlib.o, tcphandle.o and tcplink.o and the symbols 
in question are inet_addr, inet_aton and inet_ntoa). Any idea how to solve 
this problem? As you know libtool doesn't let me create a library with 
unresolved symbols (btw, all of the symbols are defined in one of the shared 
libs (libbind.so) I'm linking against. If I use a simple project file for use 
with the IDE provided by BeOS I can successfully build the shared library if 
I include arpa/inet.h which defines these symbols.

Also I need to link against two shared libraries in order to have a working 
tcp/ip setup (libsocket.so and libbind.so), but unfortunatly have no clue 
about configure and friends and thus don't know how to tell the make system 
how to link against these libraries only on BeOS? Currently I simply added 
those to LIBADD (or something close to that ...), but I'm sure this will make 
trouble on other platforms.

Regards,
Rossi


-- 
Marcus Jacob | ro...@ai... | "Mostly Harmless"
Cyberyuppie  |   ww...@ai... |

[icqlib-dev] ["stormy" <stormy@nwco.co.jp>] icqlib: registering new uin doesn't work

[Denis V. D. <de...@nu...>]

From: "stormy" <st...@nw...>
To: <de...@nu...>
Subject: icqlib: registering new uin doesn't work
Date: Thu, 28 Sep 2000 19:13:04 +0900

Thanks for your contribution to the open source world.

Register new UIN doesn't seem to work in icqlib 1.0, 
though in the document it says 'including new UIN registration'. 

I tried using Net::ICQ the perl module to write a registration
program myself but only found the server responded with
version3 of the protocol, which I couldn't find any comprehensive
document. 

I found that the function initNewUser is commented out. 
Maybe you're in the same situation as I am.

[icqlib-dev] [Phlip Mihov <avisko@fintech.bg>] IcqLib bug

[Denis V. D. <de...@nu...>]

Date: Wed, 4 Oct 2000 13:17:07 -0700
To: de...@nu...
Subject: IcqLib bug
From: Phlip Mihov <av...@fi...>

Hi Denis,

I found a bug in IcqLib v. 1.0.0 when compiled for Win32.
Its in file tcplink.c in icq_TCPLinkAccept function.
The line that sets the socket to non-blocking mode shoud be

>> ioctlsocket(pnewlink->socket, FIONBIO, &iosflag);

instead of 

>> ioctlsocket(plink->socket, FIONBIO, &iosflag);

Regards,
Philip Mihov

Re: [icqlib-dev] icq_UserOnline

[Denis V. D. <de...@nu...>]

Roland Rabien <rr...@gu...> writes:

Oops, found this message at the bottom of my mailbox... ;)
It was my settling time here, so no wonder I lost it along with several
other emails... Sorry ;)

> (*link->icq_UserOnline)(link, remote_uin, new_status, remote_ip,
> remote_port, remote_real_ip, tcp_flag);

> For the icq_UserOnline callback, could somebody tell me the meaning of the
> new_status variable. I am getting values like 0x30013 and 0x30000 which
> don't seem to be defined in any header file. Or do I just need to figure
> them out by trial and error?

Take a look at icq_ConvertStatus2Str() function in util.c to understand
these values. For example, 0x30013 is DND (Do Not Disturb) and 0x30000 is
Online.

-- 
Denis V. Dmitrienko | E-mail: de...@nu... | ICQ#: 5538614
Home page: http://denix.org
History became legend... Legend became myth.
And some things that should not have been forgotten ...were lost.

[icqlib-dev] Documentation on icqlib

[Alfredo R. <ar...@ya...>]

Hello fellas!

I'm making a small clone tool for my site that sends several url
messages to several users... i'm hacking comicq, but there are some
things (functions) I still don't understand from icqlib.

Is there any written documentation on the use of the functions, and /or
a template for using them? Anything better that reading the whole icq
protocolo files (again!!!)

Thanks alot

Alfredo

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

[icqlib-dev] icqlib doesnt free memory

[Roland R. <rr...@gu...>]

I'm having some problems with icqlib, I was wondering if anybody knows whats
up.

My app runs file for while, but then I go away for an hour or so and when I
come back I find that my app is now sucking back about 100 MB or so of RAM.

The problem (I'm guessing) is that icqlib is mallocing memory and not giving
it back, once it starts happening it seems to happen ever second call to
icq_Main() another 4K (est) get malloced, somewhere inside a call to
list_traverse() on the line if(!(f=(*item_f)(i->item, ap))).

But after I get this far I'm lost on how to try to find the problem. Can
anybody offer some advice?

I think the problem has something to do with two icq clients with one IP
address. Either because of NAT or two clients on one machine. I can cause
the problem to happen by starting to clients and sending a message between
them.

Any ideas?
Thanks,
Roland

[icqlib-dev] icq_UserOnline

[Roland R. <rr...@gu...>]

(*link->icq_UserOnline)(link, remote_uin, new_status, remote_ip,
remote_port, remote_real_ip, tcp_flag);

For the icq_UserOnline callback, could somebody tell me the meaning of the
new_status variable. I am getting values like 0x30013 and 0x30000 which
don't seem to be defined in any header file. Or do I just need to figure
them out by trial and error?

thx.

[icqlib-dev] Latest changes update

[Denis V. D. <de...@nu...>]

2000-08-13  Denis V. Dmitrienko  <de...@nu...>

	* icqlib/tcphandle.c:
	Cyrillic recoding on received URL description added.

	* icqlib/icq.h.in, icqlib/util.c: icq_Genders[] array have been added.

-- 
Denis V. Dmitrienko | E-mail: de...@nu... | ICQ#: 5538614
Home page: http://www.cn.ua/~denis
History became legend... Legend became myth.
And some things that should not have been forgotten ...were lost.

[icqlib-dev] Latest changes

[Denis V. D. <de...@nu...>]

2000-08-13  Denis V. Dmitrienko  <de...@nu...>

	* icqlib/icq.h.in, icqlib/util.c: icq_Genders[] array have been added.

-- 
Denis V. Dmitrienko | E-mail: de...@nu... | ICQ#: 5538614
Home page: http://www.cn.ua/~denis
History became legend... Legend became myth.
And some things that should not have been forgotten ...were lost.

[icqlib-dev] Latest changes

[Denis V. D. <de...@nu...>]

2000-08-13  Denis V. Dmitrienko  <de...@nu...>

	* icqlib/udp.c: Patch #101057 have been applied.

-- 
Denis V. Dmitrienko | E-mail: de...@nu... | ICQ#: 5538614
Home page: http://www.cn.ua/~denis
History became legend... Legend became myth.
And some things that should not have been forgotten ...were lost.

Re: [icqlib-dev] Authorizations etc...

[Denis V. D. <de...@nu...>]

Bill Soudan <we...@ri...> writes:

> I'm not working on anything like that, and I think it would be a great
> thing to implement - go for it!

> I'm not sure you'd want to do this in icqlib, though, it makes more sense
> for the client program (kicq) to handle this stuff, to me anyway.

I fully agree with Bill.
Looking forward to see some new functionality from Ben Reser soon! ;)

Since this is more related to kicq, I forward it there.

-- 
Denis V. Dmitrienko | E-mail: de...@nu... | ICQ#: 5538614
Home page: http://www.cn.ua/~denis
History became legend... Legend became myth.
And some things that should not have been forgotten ...were lost.

Re: [icqlib-dev] Authorizations etc...

[Denis V. D. <de...@nu...>]

Ben Reser <be...@re...> writes:

> It's pretty clear to me that the client is rather laking in the area of
> authorization handling and in privacy functionality.  Frankly I'd just assume

What do you mean by authorization? Authorization requests are supported.

> stop getting some of the random spam that I get.  So I'd like to get it setup
> so that only people on my contactlist can send to me.  And while I'm at it I'd

Yeah, this is good idea to implement ignore list and receiving messages
from people in contact list only!

> figured I would implement all the other privacy options of the windows ICQ
> client...  

Cool! I just recommend you to look how other things implemented in kicq and
try to keep the style as close as possible. This is not only about
indentation style, but about using QLayouts, avoiding global variables and
so on. And as ususal, if you don't know how to make some things, ask here.

> I know there was a security/privacy settings box in kicq at one point in time,
> so is anyone else working on this?  Is there any reason that I shouldn't work
> on this?

This menu item was just empty and was removed before release to avoid
unnecessary user's questions.
You can put your hands on it since nobody else working on it right now.

-- 
Denis V. Dmitrienko | E-mail: de...@nu... | ICQ#: 5538614
Home page: http://www.cn.ua/~denis
History became legend... Legend became myth.
And some things that should not have been forgotten ...were lost.

[icqlib-dev] icqlib-1.0.0 have been released!

[Denis V. D. <de...@nu...>]

Hi everybody!

I am pleased to announce that long-awaited next release of icqlib version
1.0.0 now available to download from SourceForge download section -
http://download.sourceforge.net/icqlib/icqlib-1.0.0.tar.gz.

Home page of icqlib project also have been updated -
http://kicq.sourceforge.net/icqlib.shtml

-- 
Denis V. Dmitrienko | E-mail: de...@nu... | ICQ#: 5538614
Home page: http://www.cn.ua/~denis
History became legend... Legend became myth.
And some things that should not have been forgotten ...were lost.

Re: [icqlib-dev] Authorizations etc...

[Bill S. <we...@ri...>]

On Sun, 30 Jul 2000, Ben Reser wrote:

> It's pretty clear to me that the client is rather laking in the area
> of authorization handling and in privacy functionality.  Frankly I'd
> just assume stop getting some of the random spam that I get.  So I'd
> like to get it setup so that only people on my contactlist can send to
> me.  And while I'm at it I'd figured I would implement all the other
> privacy options of the windows ICQ client...
> 
> I know there was a security/privacy settings box in kicq at one point
> in time, so is anyone else working on this?  Is there any reason that
> I shouldn't work on this?

I'm not working on anything like that, and I think it would be a great
thing to implement - go for it!

I'm not sure you'd want to do this in icqlib, though, it makes more sense
for the client program (kicq) to handle this stuff, to me anyway.

Bill

[icqlib-dev] Authorizations etc...

[Ben R. <be...@re...>]

It's pretty clear to me that the client is rather laking in the area of
authorization handling and in privacy functionality.  Frankly I'd just assume
stop getting some of the random spam that I get.  So I'd like to get it setup
so that only people on my contactlist can send to me.  And while I'm at it I'd
figured I would implement all the other privacy options of the windows ICQ
client...  

I know there was a security/privacy settings box in kicq at one point in time,
so is anyone else working on this?  Is there any reason that I shouldn't work
on this?

-- 
Ben Reser <be...@re...>
http://ben.reser.org

"Heuristics are bug ridden by definition. If they didn't
have bugs, then they'd be algorithms."