[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