icqlib-dev

Re: [icqlib-dev] ICQLib on BeOS

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

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

> Eugenia Loli was kind enough to provide a BeOS box for me to attempt to
> compile icqlib on.  We got together today over IRC, here's a quick summary
> for everyone's benefit of how it went:

Great news. Thanks, Eugenia!

> 3) libtool has problems creating a shared library on BeOS, but the static
> library appears to build fine.  libtool is way beyond my expertise, but if
> someone else may be able to help here, please let us know.

I probably can help with shared libraries and libtool...

> So what I'm going to do now is commit fixes so icqlib will at least
> compile on BeOS, but explicitly note that TCP will not work until BONE is
> ready and that shared libraries do not work.

Good point. We are going to have README.BeOS file. ;)

-- 
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] Re: ICQLib on BeOS

[Eugenia L. <el...@ho...>]

Hi all.
I posted the modified source code, and static/dynamic libs on BeBits for 
public consumption:
http://www.bebits.com/app/1932
BTW, Jbq, a Be engineer, was able to build the .so library manually by 
using:
gcc -nostart -Xlinker -whole-archive libicq.a -Xlinker -soname=libicq.so -o 
libicq.so

I will email you when BONE will be released, so a more complete port can 
take place. Thank you for your help! :)

Best Regards,
Eugenia

---
BeOS Quick Info:
http://www.ukbug.org/beos.html



>From: Bill Soudan <we...@ri...> To: icq...@li...
>CC: Eugenia Loli <el...@ho...> Subject: ICQLib on BeOS
>Date: Sun, 21 Jan 2001 15:08:57 -0500 (EST)
>
>
>Hi all,
>
>Eugenia Loli was kind enough to provide a BeOS box for me to attempt to
>compile icqlib on.  We got together today over IRC, here's a quick summary
>for everyone's benefit of how it went:
>
>1) Currently, BeOS has its socket stuff (fd_set, socket, accept, etc) in
>the socket.h header.  We need a
>
>#ifdef __BEOS__
>#include <socket.h> #endif
>
>in icq.h or else there's lots of undefined errors.
>
>2) BeOS doesn't support asynchronous TCP connects or the SO_ERROR
>getsockopt option.  However, once the new BeOS networking stack (BONE) is
>in, it will.  Eugenia recommended we just hold off here, and wait for
>BONE, instead of spending the time to make all the connect calls blocking
>(which is the way they used to be, anyway :).  In order to get icqlib to
>compile on her box though, I just commented out the problem code:  the
>getsockopt call in icq_TCPLinkOnConnect.  This will make TCP
>non-functional on BeOS, but at least it compiles!  UDP should be
>unaffected, so just make sure to send all messages
>ICQ_SEND_THRUSERVER.  Chat and file transfer support are TCP only, though,
>so these functions will not work at all :(
>
>3) libtool has problems creating a shared library on BeOS, but the static
>library appears to build fine.  libtool is way beyond my expertise, but if
>someone else may be able to help here, please let us know.
>
>So what I'm going to do now is commit fixes so icqlib will at least
>compile on BeOS, but explicitly note that TCP will not work until BONE is
>ready and that shared libraries do not work.
>
>Eugenia, if you could let us know when BONE has been released,
>we'll remove those fixes and then maybe we can get together and try to get
>icqlib compiled again, this time with full functionality.  And let us know
>when you have your icq client working, so we can add it to the list
>of applications that use icqlib :)
>
>Bill
>
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

[icqlib-dev] ICQLib on BeOS

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

Hi all,

Eugenia Loli was kind enough to provide a BeOS box for me to attempt to
compile icqlib on.  We got together today over IRC, here's a quick summary
for everyone's benefit of how it went:

1) Currently, BeOS has its socket stuff (fd_set, socket, accept, etc) in
the socket.h header.  We need a

#ifdef __BEOS__
#include <socket.h>
#endif

in icq.h or else there's lots of undefined errors.

2) BeOS doesn't support asynchronous TCP connects or the SO_ERROR
getsockopt option.  However, once the new BeOS networking stack (BONE) is
in, it will.  Eugenia recommended we just hold off here, and wait for
BONE, instead of spending the time to make all the connect calls blocking
(which is the way they used to be, anyway :).  In order to get icqlib to
compile on her box though, I just commented out the problem code:  the
getsockopt call in icq_TCPLinkOnConnect.  This will make TCP
non-functional on BeOS, but at least it compiles!  UDP should be
unaffected, so just make sure to send all messages
ICQ_SEND_THRUSERVER.  Chat and file transfer support are TCP only, though,
so these functions will not work at all :(

3) libtool has problems creating a shared library on BeOS, but the static
library appears to build fine.  libtool is way beyond my expertise, but if
someone else may be able to help here, please let us know.

So what I'm going to do now is commit fixes so icqlib will at least
compile on BeOS, but explicitly note that TCP will not work until BONE is
ready and that shared libraries do not work.

Eugenia, if you could let us know when BONE has been released,
we'll remove those fixes and then maybe we can get together and try to get
icqlib compiled again, this time with full functionality.  And let us know
when you have your icq client working, so we can add it to the list
of applications that use icqlib :)

Bill

[icqlib-dev] Today's commits

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

2001-01-20  Bill Soudan  <so...@kd...>

        * icqlib/chatsession.c, icqlib/icq.h.in: added documentation

        * icqlib/icqbyteorder.h: applied patch from Eric Warmenhoven
        to fix byte order on HP/UX.

        * icqlib/tcplink.h: applied patch from Eric Warmenhoven to
        fix compilation on FreeBSD.

Re: [icqlib-dev] Documentation work...

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

On Sat, 20 Jan 2001, Denis V. Dmitrienko wrote:

> Bill Soudan <we...@ri...> writes:
> 
> Great work, Bill! I like it so far. I'll spend some time documenting UDP
> and general stuff in icqlib.

Thanks!  Great, maybe we can have some complete docs by icqlib-2.0.0!  

BTW, speaking of 2.0... do you have any thoughts on it?  All I want to get
in before 2.0 is the stuff I posted on my todo list, (documentation, event
interface is still todo) and then I'm ready.  We'll also have python
bindings (yay!) and maybe even the C++ bindings.  What does everyone else
want to see for 2.0?

> Is it doxygen advertisement? ;) Do you have any affiliations with doxygen's
> author? ;)

laugh, it does sound like it, huh?  I just think doxygen is the greatest
thing since sliced bread.  :)  One of the best open source projects I
think... besides kicq and icqlib, of course ;))

> BTW, about main icqlib page. As I already sayd some time ago, I have
> icqlib.org domain (as well as kicq.org). Anybody willing to maintain web
> icqlib/kicq site(s)?

Yeah, this would be a great place to put it!

I'd like to say yes, but I'd rather spend the time coding and I don't know
HTML very well.  I have a friend that does some web design, maybe he'd
like a side project.  I'll ask him. :)

Bill

Re: [icqlib-dev] Documentation work...

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

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

> I've started progress on icqlib documentation using the excellent inline
> documentation tool, Doxygen (http://www.stack.nl/~dimitri/doxygen/)...
> here's what it looks like currently:
> 
> http://neon.yi.org/~bills/doc/icqlib/

Great work, Bill! I like it so far. I'll spend some time documenting UDP
and general stuff in icqlib.

> I spent the most time on the chat session documentation, though there's a
> little for the ICQLINK structure too.  Here's direct links to the
> interesting stuff:
> 
> http://neon.yi.org/~bills/doc/icqlib/group_ChatSession.html
> http://neon.yi.org/~bills/doc/icqlib/struct_icq_link.html
> 
> Of course this is extremely far from being complete, but I thought I'd
> offer it up so I could get some initial comments, make sure everyone likes
> the Doxygen output,

Everyone or at least majority likes it! ;)

> etc.  It also produces documentation in man, rtf, and
> latex/ps/pdf format.  In particular, I was extremely impressed by the
> latex output (as viewed in pdf format, anyway) - very slick and
> professional.

Is it doxygen advertisement? ;) Do you have any affiliations with doxygen's
author? ;)

> I'll keep this link updated with the most current documentation at all
> times, so feel free to bookmark it.  Once it's reasonably complete, I'll
> put it up on the main icqlib page, of course.

BTW, about main icqlib page. As I already sayd some time ago, I have
icqlib.org domain (as well as kicq.org). Anybody willing to maintain web
icqlib/kicq site(s)?

-- 
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 work...

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

I've started progress on icqlib documentation using the excellent inline
documentation tool, Doxygen (http://www.stack.nl/~dimitri/doxygen/)...
here's what it looks like currently:

http://neon.yi.org/~bills/doc/icqlib/

I spent the most time on the chat session documentation, though there's a
little for the ICQLINK structure too.  Here's direct links to the
interesting stuff:

http://neon.yi.org/~bills/doc/icqlib/group_ChatSession.html
http://neon.yi.org/~bills/doc/icqlib/struct_icq_link.html

Of course this is extremely far from being complete, but I thought I'd
offer it up so I could get some initial comments, make sure everyone likes
the Doxygen output, etc.  It also produces documentation in man, rtf, and
latex/ps/pdf format.  In particular, I was extremely impressed by the
latex output (as viewed in pdf format, anyway) - very slick and
professional.

I'll keep this link updated with the most current documentation at all
times, so feel free to bookmark it.  Once it's reasonably complete, I'll
put it up on the main icqlib page, of course.

Enjoy,
Bill

[icqlib-dev] SourceForge News & Current SourceForge Service Status Report

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

SourceForge News

Posted By: blkadder
Date: 2001-Jan-16 14:33
Summary: Major Upgrade Happening Tomorrow Morning

Hi Folks, 

We will be performing our migration to a LDAP-based authentication during
our recently established normal maintentance window (Wednesdays 1 am - 3
am. PST)

This is a much anticipated switch for us and for some of you as well. :-)

With the switch, many of the problems we(and more importantly you) have
been experiencing should be resolved. These include problems with account
creation, permissions issues, and CVS access problems due to duplicate
project and user names.

The switch will also enable us to begin offering restricted shell access to
the CVS server so that users can install and manipulate their own
repositories directly. This access will NOT be enabled immediately after
the switch, but should be functional by Monday, Jan 22nd.

Additionally we will also be able to begin offering access to the compile
farm, expected to be ready Wednesday, Jan 24th.

While we have tested what we are installing and do not expect any major
problems the introduction of fundamental and wide-spread changes to live
systems and software does introduce some level of risk that we may
encounter unforseen issues.

We have implemented a regularly updated Site Status page as promised, and
added a link to this page on the left-hand navigation bar.

If you have any problems, please check this page FIRST before submitting
support requests. If any issues are or could affect a substantial number of
users, the Site Status page is the best place to go for current news and
information regarding known issues.

As always, thanks for your support.

-----------------------------------------------------------------------

Current SourceForge Service Status Report

CURRENT status as of Jan 16th, 2001 is as follows:

MAJOR UPGRADE HAPPENING WEDNESDAY JAN 17th: We will be performing our
migration to a LDAP-based authentication during our normally scheduled
maintentance window (Wednesdays 1 am - 3 am. PST) as well as performing
other miscellaneous maintenance tasks. During this time users may
experience periods of unavailability of certain systems and/or
services. NEW PROJECT/ACCOUNT ACTIVATION/USE: Due to the move and all the
new infrastructure, account/project activation is a somewhat manual
process. This means that contrary to the message received when a new
project/account is approved it may take up to 72 hours until ssh access and
home directories are enabled. We hoped to have this fixed by Friday, Jan
19th.

STATS: As you all know, they're completely broken. We are approaching this
from two directions.

The first is to get the current cruft back up. The person responsible for
this is out sick and hopefully will be back early next week to start
working on this. I hope to have an ETA as soon as he has a chance to take a
look at things.

The second way we are addressing this is to do a complete overhaul of the
stats system, which fundamentally does not scale the way we want and is
error-prone. This is the *real* fix, and should be much more robust and
statistics that are more accurate. We now have the logging module we needed
and will be testing it.

FTP: We are currently operating with a single FTP server located on the
East Coast which is bandwidth constrained.

We have a second FTP server recently located at Ibiblio's facilities which
we are currently syncing against the first server. Unfortunately we are
experiencing kernel problems with this machine are in the process of
investigating the problem.

We have a third FTP server destined to be our replacement West Coast server
that is apparently failed burn-in testing and for which we are awaiting a
replacement part for. Once the part is received it will undergo burn-in
testing and we'll bring it online to begin the sync process with the main
FTP server(takes ~1 week.)

Shell Server: There have been several reports regarding the inability to
run certain software on the shell server. We are in the process of
formulating a policy statement on the purpose of the shell server which
will outline what types of activities and software will be supported on the
machine. This will be released next week.

Compile Farm: The compile farm is built and is currently being racked. With
the conversion to LDAP authentication, we hope to have it operational by
Wednesday, Jan 24th.

-- 
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] Session interface cleanups done...

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

This should be very close to the final version of the Chat and File
session interfaces.  I'm pretty happy with how they look now - I think
they're clean and consistent.

Michael, let me know if you notice anything that can be improved as you
implement the Python bindings.  I'm especially interested in making the
interface fit well with an OO model, since I'd like to write C++ bindings
that mirror your Python bindings someday.

I'll add better documentation soon.  I wanted to get them in ASAP so the
work can begin on the Python bindings.

Bill

[icqlib-dev] Today's commits

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

2001-01-16  Bill Soudan  <we...@ri...>

        Phase 2 of my interface cleanups.  See CHANGES_SINCE_1.0 for
        more details.  icqlib developers be sure to look at
        socketmanager.c - all future socket create/delete/handling needs
        to go through this code so the new icq_SocketNotify callback
        works properly.

        * icqlib/socketmanager.c, icqlib/socketmanager.h,
        icqlib/Makefile.am: added socketmanager.c & socketmanager.h

        * icqlib/contacts.h, icqlib/list.h, icqlib/proxy.c: cleanup

        * icqlib/chatsession.c, icqlib/chatsession.h, icqlib/filesession.c,
        icqlib/icq.h.in, icqlib/icqevent.c, icqlib/icqevent.h,
        icqlib/icqlib.c, icqlib/icqlib.h, icqlib/tcp.c,
        icqlib/tcpchathandle.c, icqlib/tcpfilehandle.c,
        icqlib/tcphandle.c, icqlib/tcplink.c, icqlib/tcplink.h:
        Rework chat and file interfaces; implement socket notifications.

[icqlib-dev] Latest changes

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

2001-01-16  Denis V. Dmitrienko  <de...@nu...>

	* icqlib/contacts.c, icqlib/contacts.h, icqlib/icq.h.in, icqlib/udp.c:
	Invisible list has been finished.

-- 
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 changes

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

2001-01-15  Denis V. Dmitrienko  <de...@nu...>

	* icqlib/tcplink.c:
	Applied patch from Ilya Melamed <il...@or...> which fixes random
	icq_TCPLinkAccept() fails.

	* icqlib/udphandle.c:
	Applied patch from Andrey Chernomyrdin <an...@ex...> to
	handle icq2000 specific "You've been added" packet.

	* icqlib/icq.h.in:
	Prototype for icq_SendInvisibleList() has been added.

	* .cvsignore, icqlib.spec.in:
	Applied patch from Ryan Weaver <ry...@in...> for .spec file
	generation.

	* configure.in, Makefile.am, Makefile.cvs, admin/acinclude.m4.in,
	admin/config.guess, admin/config.sub, admin/icqlib.m4.in,
	admin/install-sh, admin/libtool.m4.in, admin/ltconfig,
	admin/ltmain.sh, admin/missing, admin/mkinstalldirs,
	acinclude.m4.in, am_edit, config.guess, config.sub, icqlib.m4.in,
	install-sh, libtool.m4.in, ltconfig, ltmain.sh, missing,
	mkinstalldirs:
	autoconf/automake files have been moved to admin directory.

	* TODO, icqlib/icqlib.c: Cleanup.

-- 
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] icqlib/kicq crash on long TCP messages (was: [bofh@buh.rbc.ru] kicq break down)

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

Hi.

I've mined my mailbox to find any evidences on subject... Here is beautiful
example. ;)

-- 
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.

From: bo...@bu...
Date: Fri, 4 Aug 2000 11:02:07 +0400
To: "Denis V . Dmitrienko" <de...@nu...>
Subject: kicq break down

$ kicq
packet received! { length=26 }
icq_Packet 811ac90 { id=0, cursor=1a, length=26 }
0000: 1a 00 ff 07 00 00 00 18 46 00 00 f5 e7 4e 04 00 ........F....N..
0010: 00 00 00 d4 6f 41 47 04 18 46 00 00             ....oAG..F..
packet received! { length=563 }
icq_Packet 811ce10 { id=0, cursor=233, length=563 }
0000: 33 02 f5 e7 4e 04 03 00 ee 07 00 00 f5 e7 4e 04 3...N.........N.
0010: 01 00 0c 02 68 74 74 70 3a 2f 2f 74 6e 73 2e 73 ....http://tns.s
0020: 64 73 75 2e 65 64 75 2f 7e 64 69 65 62 65 6c 2f dsu.edu/~diebel/
0030: 6a 64 62 63 2f 63 6f 6e 74 65 6e 74 73 2e 68 74 jdbc/contents.ht
0040: 6d 0d 0a 0d 0a 4f 72 61 63 6c 65 20 4a 44 42 43 m....Oracle JDBC
0050: 20 64 72 69 76 65 72 73 20 61 72 65 20 62 65 74  drivers are bet
0060: 61 20 71 75 61 6c 69 74 79 20 70 72 6f 64 75 63 a quality produc
0070: 74 73 2e 20 4f 72 61 63 6c 65 20 64 6f 65 73 20 ts. Oracle does
0080: 6e 6f 74 20 67 75 61 72 61 6e 74 65 65 20 74 68 not guarantee th
0090: 61 74 20 74 68 65 79 20 61 72 65 20 6f 66 20 70 at they are of p
00a0: 72 6f 64 75 63 74 69 6f 6e 20 71 75 61 6c 69 74 roduction qualit
00b0: 79 20 6f 72 20 74 68 61 74 20 61 6c 6c 20 65 6c y or that all el
00c0: 65 6d 65 6e 74 73 20 6f 66 20 74 68 65 69 72 20 ements of their
00d0: 64 6f 63 75 6d 65 6e 74 65 64 20 66 75 6e 63 74 documented funct
00e0: 69 6f 6e 61 6c 69 74 79 20 77 6f 72 6b 2e 20 4f ionality work. O
00f0: 72 61 63 6c 65 20 68 61 73 2c 20 68 6f 77 65 76 racle has, howev
0100: 65 72 2c 20 74 65 73 74 65 64 20 74 68 65 73 65 er, tested these
0110: 20 4a 44 42 43 20 64 72 69 76 65 72 73 20 65 78  JDBC drivers ex
0120: 74 65 6e 73 69 76 65 6c 79 20 61 67 61 69 6e 73 tensively agains
0130: 74 20 4f 72 61 63 6c 65 37 20 61 6e 64 20 4f 72 t Oracle7 and Or
0140: 61 63 6c 65 38 20 73 65 72 76 65 72 73 2e 20 0d acle8 servers. .
0150: 0a 0d 0a 4f 72 61 63 6c 65 20 64 6f 65 73 20 6e ...Oracle does n
0160: 6f 74 20 73 75 70 70 6f 72 74 20 74 68 65 73 65 ot support these
0170: 20 64 72 69 76 65 72 73 20 74 68 72 6f 75 67 68  drivers through
0180: 20 69 74 73 20 77 6f 72 6c 64 77 69 64 65 20 73  its worldwide s
0190: 75 70 70 6f 72 74 20 6f 72 67 61 6e 69 7a 61 74 upport organizat
01a0: 69 6f 6e 20 69 6e 20 61 6e 79 20 77 61 79 2e 20 ion in any way.
01b0: 55 73 65 72 73 20 61 72 65 20 65 6e 63 6f 75 72 Users are encour
01c0: 61 67 65 64 20 74 6f 20 75 73 65 20 74 68 65 73 aged to use thes
01d0: 65 20 64 72 69 76 65 72 73 20 61 6e 64 20 74 6f e drivers and to
01e0: 20 72 65 70 6f 72 74 20 61 6e 79 20 70 72 6f 62  report any prob
01f0: 6c 65 6d 73 20 74 68 65 79 20 65 6e 63 6f 75 6e lems they encoun
0200: 74 65 72 20 62 79 20 73 65 6e 64 69 6e 67 20 65 ter by sending e
0210: 6d 61 69 6c 20 74 6f 3a 20 0d 0a 0d 0a 0d 0a 00 mail to: .......
0220: 00 00 00 00 d4 6f 41 47 18 46 00 00 04 00 00 10 .....oAG.F......
0230: 00 ed ff ff ff                                  .....
packet processed from uin: 72280053:
	command: 7ee type: 1   
	status: 0    
	command_type: 10
	message http://tns.sdsu.edu/~diebel/jdbc/contents.htm 
Oracle JDBC drivers are beta quality products. Oracle does not guarantee that they are of production 
quality or that all elements of their documented functionality work. Oracle has, however, tested these 
JDBC drivers extensively against Oracle7 and Oracle8 servers. Oracle does not support these drivers through 
its worldwide support organization in any way. Users are encouraged to use these drivers and toreport any 
problems they encounter by sending email to:      




	id: ffffffed
tcp message packet received from 72280053 { sequence=ffffffed }
41 bytes sent on socket 8, result 42
icq_Packet 811ee30 { id=0, cursor=28, length=40 }
0000: 28 00 54 b1 09 04 03 00 da 07 00 00 54 b1 09 04 (.T.........T...
0010: 01 00 01 00 00 e1 0e 00 00 e1 0e 00 00 00 11 00 ................
0020: 00 04 00 00 00 00 ce d1 d1 d1                   ..........
tcp message ack sent to uin 72276680 { sequence=d1d1d1ce }
Segmentation fault (core dumped)

[icqlib-dev] [Eric Peyton <epeyton@epicware.com>] icqlib

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

From: Eric Peyton <ep...@ep...>
To: de...@nu...
Subject: icqlib

Denis,

I am the author of Fire.app, an open sourced multiprotocl IM client for
Mac OS X.  I currently support libfaim, libyahoo and I use libicq (from
kicq).  It's good work :)  Thanks for gpl'ing it and releasing it.

One question.  everything currently works fine.  I can send and recieve
messages about 90% of the time.  (I have some issues with people not
showing up as online - it seems I never get the callback that they are
online - they are visibile and all), but I digress.

I am now to the point where I wnat to implement file send and file
recieve.  So I set up the pointers for the file recieve callback and tried
sending a file from 1CQ 2000a to my icqlib client.

However ICQ2000a says that the user can't accept file sends because it's
not a DIRECT connection.  How do I remedy that?  I see that you support
UDP and TCP and THRUSERVER and DIRECT connections, but how do I set that I
want to use DIRECT connections?

I am now downloading kicq to scour the source.

Any help is appreciated.

Thanks,

Eric

Eric Peyton
ep...@ep...

Software and Source for Mac OS X

[icqlib-dev] [Jean-Hugues ROYER <jhroyer@joher.com>] icqlib

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

To: de...@nu...
From: Jean-Hugues ROYER <jh...@jo...>
Subject: icqlib

Hi,

Do you plan on doing a function (in udp.c) like icq_SendAuthReq() that
sends an authorization request (not reply) to the mirrablis clients.

Do you plan on supporting (in udphandle.c) the v5 0x15e message you get
when someone try to send you a message trough tcp, you already put
the define in udp.h (UDP_CMD_REVERSE_TCP_CONN) tho.

In fact i'm looking for a way to tell to the server to only accept incoming
msgs sent thru server or to tell the remote sender to send thru the server,
any idea is welcome :)

I'm currently tracking down a problem of malloc/free in your libs that
erronously
free some pointer twice, i will keep you posted.

Thanks. 

Re: [icqlib-dev] RFC: event interface proposal

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

On Fri, 12 Jan 2001, Denis V. Dmitrienko wrote:

> > 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.
> 
> How hard do you think it will be to implement/support both APIs?

Well, my plans to implement this event thing have always gone like this:

1) write the icq_event code.  don't export it yet

2) make all the existing functions use the event code internally, in
   order to test it

   e.g.

   int icq_SendMessage(int destination_uin, const char *msg, ... )
   {
       icq_MessageEvent message_event = icq_MessageEventNew();

       message_event->uin = destination_uin;
       message_event->message = msg;
       
       icq_SendEvent(message_event, ...);
   }

3) wait a while until all the bugs are squashed...

4) export the icq event interface

So basically we'll just leave the other methods there after the event
interface is exported, keep both.  Won't be hard at all!

Bill

[icqlib-dev] [dan@iquest.net] [micq] mICQ author Matt Smith

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

Reply-To: mi...@ph...
From: da...@iq...
To: mi...@ma...
Date: Tue, 9 Jan 2001 23:32:26 -0500 (EST)
Subject: [micq] mICQ author Matt Smith


 I recently have been given the sad news that the author of mICQ has passed
 away recently from medical complications.

 You may read the obituary here: http://www.telegram.com/news/obits/smith1.html

 According to a close friend of Matts, the article incorrectly reports that
 the cause of death was a motor vehicle accident, I can neither confirm nor
 deny this.




      ========================================================
      Another "unoffical, not-sponsored-by-Mirabilis-one-bit"
      ICQ Clone Development List.

      To unsubscribe email mic...@mi...

Re: [icqlib-dev] RFC: event interface proposal

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

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

I've removed crossposting to Michael Hudson since he's already subscribed
to this list. ;)

> 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.

How hard do you think it will be to implement/support both APIs?

> A few example timelines:
> 
> client:  icq_SendEvent(icqlink, login_event, ICQ_SEND_BESTWAY)==1;

ICQ_SEND_THRUSERVER is better since sending login via TCP isn't actually
possible (at least with the current protocols we support)

> 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;

The same thing with search - this is server command, so use
ICQ_SEND_THRUSERVER instead of ICQ_SEND_BESTWAY.

> 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_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; // ??

This is homepage ;)

>    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

Looks great! I haven't seen "struct icq_Event" though.

-- 
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] ["sumanth jv" <sumanthjv@hotmail.com>] Please Help Me !!!

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

From: "sumanth jv" <sum...@ho...>
To: de...@nu...
Subject: Please Help Me !!!
Date: Thu, 11 Jan 2001 19:32:35 

Respected Sir,

I have searched sooooo much on the net for doccumentation on icqlib but 
havent seemed to find anythin at all :-(. I desperately need to know how to 
use it for a college project of mine. I am a 20 year old student from India. 
Please let me have any docs u have on it.


Thanking You

Sumanth J.V
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Re: [icqlib-dev] SMS in ICQ 2000

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

On Wed, Dec 20, 2000 at 02:21:28PM +0000, Tim Wu wrote:
> I need the SMS function of icq 2000 very much.
> Will it be implemented in icqlib?
> 
> If I want to do it by myself and then where can I get the protocol spec?
> I have checked icq protocol v5 but nothing regards SMS.

All of the ICQ protocol's have to be reverse engineered.  If someone else
hasn't done it you'll have to do it.  So since you can't find the info you'd
have to do it.

-- 
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] SMS in ICQ 2000

[Tim Wu <ti...@co...>]

Bill Soudan wrote:
> 
> GAIM uses icqlib for its ICQ plugin!
> 
> Bill
> 
> ---------- Forwarded message ----------
> Date: Tue, 19 Dec 2000 02:04:29 -0800
Hi! All,

I need the SMS function of icq 2000 very much.
Will it be implemented in icqlib?

If I want to do it by myself and then where can I get the protocol spec?
I have checked icq protocol v5 but nothing regards SMS.

[icqlib-dev] (fwd) new application using icqlib!

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

GAIM uses icqlib for its ICQ plugin!

Bill

---------- Forwarded message ----------
Date: Tue, 19 Dec 2000 02:04:29 -0800
From: Eric Warmenhoven <war...@ya...>
To: we...@ri...
Subject: icqlib 1.1.0

Hello,

I'm not sure if you know, but gaim's using icqlib for its icq support now.
I just got 1.1.0 out of CVS, and tried it out. It worked fine, except for
one little thing. icq_ICQLINKNew doesn't return the link that it creates.

/bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..     -Wall -g -O2 -c icqlib.c
icqlib.c: In function `icq_ICQLINKNew':
icqlib.c:291: warning: control reaches end of non-void function

I had it return link and everything works great :)

Thanks for the library, it's working well.

Eric

[icqlib-dev] Today's commits

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

2000-12-19  Bill Soudan  <we...@ri...>

        * icqlib/chatsession.c, icqlib/contacts.c, icqlib/eventhandle.c,
        icqlib/filesession.c, icqlib/icq.h.in, icqlib/icqlib.c,
        icqlib/icqlib.h, icqlib/queue.c, icqlib/stdpackets.c,
        icqlib/tcp.c, icqlib/tcplink.c icqlib/udp.c: moved some ICQLINK
        members to ICQLINK_private structures, added icq_ICQLINKNew and
        icq_ICQLINKDelete functions which replace icq_Init and icq_Done

        * CHANGES_SINCE_1.0: lists source incompatable changes since
        1.0 release.

        * VERSION: bumped version number to 1.1

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

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

What about if all the calls to malloc and free were replaced with function
pointers so the app could provide its of malloc and free routines if it
wanted, or if icqlib did try to free abything malloced by the app.

Does anybody know if file transfers work in the Win32 version?

Also:

When a user profile tells that the user is in France, Miranda says Monaco.

I think the problem is in util.c

icq_ArrayType icq_Countries[] = {
{"USA",1},
{"Russia",7},
{"Egypt",20},
{"South Africa",27},
{"Greece",30},
{"Netherlands",31},
{"Belgium",32},
{"France",33},
{"Monaco",33}, <---- remove this line
{"Spain",34},

I think that Monaco uses french telecom, they share the phone country code
with France. They does not have country number (Still a stupidness from
Mirabillis, they also prevent users to say that I speak Breton language,
because they use number in the language list, and Breton is not in their
list).

and

Found a couple misspellings of the country field in the User Details.

* Costa Rica (not Costa Rice)
* Colombia (not Columbia)


Roland Rabien
http://miranda-icq.sourceforge.net/

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

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

On Thu, Dec 14, 2000 at 06:30:20PM -0500, Bill Soudan wrote:
> A friend of mine was asking about this too.  Seems to be a popular
> feature, though I've never used it!

I would have really liked to have this when I moved from the windows client to
kicq.  Cause then I could have sent the list to a new icq id.  Then resent it
to my normal id running under kicq instead of the windows one.

-- 
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.