[icq-devel] libicq2000 0.3.0 released

rad2k at mail.ru rad2k at mail.ru
Thu Apr 18 18:26:25 CEST 2002

> Cool, that's good work. It'd be good to get some docs back into the
> community maybe on the stricq site or something as implementations
> alone aren't the ideal way of spreading the knowledge.

Indeed. Still, even if a programmer is really willing to spread the
knowledge, its a hard and imperfect ideal to document everything
(from a programmer's point of view.)

I don't mean to harm anyone, but the 'stricq' site did need some
corrections when i very first browsed it and, at least for me,
it's down pretty often.
> I wasn't thinking of anything as specific as tying them together
> particularly.. you know just sharing information - there's a vast
> amount of work being done on the protocol for the various clients out
> there and what I consider to be a huge amount of duplication and
> wasted effort, and stuff isn't so openly shared.. which is meant to be
> what opensource is all about. Still I guess documenting is always the
> boring part :-(

Might be boring, might be hard, I find it attractive and one of the
only ways of having visual proof of your hard work. That is why I
spend time writing stuff on my docs/ directory.

> For example, I think the gnomeicu team had got a considerable way
> towards server-based lists a while ago.. but it seems you ended up
> duplicating this effort because the information wasn't openly
> documented and shared (I don't count sourcecode hidden away on a cvs
> server somewhere documenting it openly). Is there anyone from gnomeicu
> on this list?

I had no idea about gnomeicu, i never even used it since i dislike
that window manager :). You will only find a nice transparent 
e-term with YSM running in my Window Maker.

> Part of the reason I see behind this is the race in the competition
> between clients.. what with the new protocol being absolutely
> necessary to survival now, developers are falling over themselves to
> be the first to get theirs fully working again. I don't think this
> competition is beneficial in the long term, hence why I've always
> coded my protocol implementation as a separate library and have pushed
> for other people to use it too.

I believe the race is true and obvious yeah, everyone wants his
work to be fully working again, and I support the will of the
programmers since i have sometimes felt the same feeling, but
I agree with you that having a generic library and making it
public is a nice and efficient idea too.

At the first time, YSM was just a stupid project of mine for coding
an icq client for my own since i thought there were no active 
developments of v7 clients, but when i had it basically working
i met in my way zICQ and Ickle, my point is, i was about to quit
the YSM development until i found out none of those clients were
written in the C language.

I guess there are 4 main languages used to develop ICQ clients 
right now, which are perl, c, c++ and Java and this means
some kind of 'race' is required, unless we somehow join all
projects together (Which i see is way an impossible task).

> The other idea I had was to implement it in a language to appeal to
> the lowest common denominator (C) and then code wrappers for
> higher-level languages.. much like the work of the gtkmm project
> wrapping the gnome libraries. But I've started in C++ so that's what
> I'm sticking too.

I haven't really taken a look at your library source code,
but im damn sure its somehow more tidy in classes than in 
common C source code.

> Yep.. if you're doing it for any reason, doing it for your users is
> the best reason I can think of.

Hell yeah.

Btw, haven't you even started the research on online Buddy lists?

I'm out, got to get back to my job.

- Argentina!
(damn, today the dollar got up to 3,15 pesos)

> Enough rambling..
> Barnaby
> -------------------------------------------------
> icq-devel - The forum for ICQ protocol discussion
> For unsubscribe and other mailing list info, see:
> http://www.d.kth.se/~d95-mih/icq/icq-devel/

More information about the icq-devel mailing list