On Sunday 04 August 2002 20:29, Zack Rusin wrote: > Well, this question should be asked the other way around. What psi > provides that libkopete doesn't? I just want to see a list saying > "libkopete can't do ... and psi provides ..." or maybe a sample use > case like 'lets say kcoolgame wants to let users chat and it needs > to... so it can't use libkopete because...'. > At this point psi is a pure Qt lib, whereas libkopete actually uses > kdelibs. I'm not sure why we would put psi inside kdelibs when it > doesn't use anything from kdelibs. Sure it might be useful but so is > Boost and it's not a good enough reason to put it in kdelibs. My 2 eurocents why I like to see jabber as _the_ standard IM protocol in = KDE=20 (including answers your questions - warning, this is detailed, thus a lon= g=20 reading): 1) some high-level feature-comparison: Jabber is an open standard, jabber= is=20 decentralized (run your own server, choose among many free public servers= ,=20 =2E..), Jabber interfaces to other messaging systems (aol, icq, msn, yaho= o,=20 email, irc, ...), but on the server side (not much of a difference, but .= =2E. -=20 more details below) 2) about the protocol itself (this passage may apply to SIMPLE as well, o= nly=20 heard of it today, don't know it): Want to send a game invitation? With=20 jabber, you invent your own message format if there doesn't exist anythin= g=20 suitable and just send it - no one will go and misinterpret it as a text=20 message. Ever seen Coccinella? http://hem.fyristorg.com/matben/ - cool=20 whiteboard app (cross-platform due to Tcl/Tk) which works over jabber. Wa= nt=20 to have your regular jabber client running at the same time? just do so, = they=20 are independently addressable - and we didn't use any OS/Desktop support = to=20 share connections or anything.. oops, did we send a whiteboard to someone= not=20 using coccinella? no problem, he won't be flooded with undecipherable=20 rubbish, since the (every!) Jabber client can tell this is not a text=20 message. These are two examples of how the protocol itself is built for=20 interoperability, regardless of OS, Desktop, Programming language, ... Want a game with invitation and chat? No problem there, the game can conn= ect=20 as yet another presence, plain chat goes straight to the game, no need to= =20 filter and dispatch anything. So do the game's custom control messages. With other IMSs, you would have to encapsulate data in chat messages, hop= e=20 that the other side can either interpret these messages or won't choke on= =20 them, need to figure out which message is destined for which program, ... 3) interoperability with other IM systems: It has had it's weaknesses, bu= t=20 nowadays the software is stable, and other IM systems don't block anyone = any=20 longer - they seem to have recognized that it is good if others use them.= As=20 for the ease of setting this up, it can be improved, but that's a client=20 software issue. The advantage of having the server manage the multi-proto= col=20 layer is that you will have your setup always and everywhere. No KDE at w= ork?=20 Or at school? Or while visiting your grandparents? With jabber you still = get=20 all your 'foreign' connections regardless of which jabber client you use.= =20 Again, this is interoperability at work. 4) Managing contacts: Jabber uses a server side contact list, so you don'= t=20 need to interface anything on the OS. Actually, libpsi might even provide= a=20 backend for the KDE address book so it is stored on the jabber server (no= t=20 sure how fesible this is, but from my knowledge it should be doable with = not=20 too much effort). Get a public jabber account and go, no need to setup an= =20 LDAP server. (Is LDAP supported?) 5) Plain old IM: you got me there, for this an app like Kopete might be m= ore=20 suitable due to easier setup (no need to create a Jabber account). But IM= HO=20 this is not the goal of libpsi (or rather, the propsed libim...). All the= =20 non-chat elements are what makes jabber much more suitable. 6) Setup complexity: it is a small price to have one jabber account creat= ed.=20 This is painless and fast (choose from a list of public servers, enter=20 username, password and done, total 20 seconds), it is neccessary only onc= e=20 ever for a user, it doesn't conflict with your other IM accounts, it does= n't=20 entitle you to receive yet another bunch of spam via IM, client banners o= r=20 mail, and is as anonymously as you like. Now compare that to , where you register once for each product and= on=20 each computer, get tons of spam, can't trust them buggers about what they= do=20 with your data, ... - IMHO a small price to pay. For the kdegames case,=20 someone could even provide a public kgame-only jabber server with=20 auto-registration, so the registering step could be handled transparently= =2E=20 This would also eliminate the problem that you might want to play with on= e=20 MSN and one ICQ user, having those accounts you can see them, but they ca= n't=20 see each other. Enforcing Jabber eliminates that. Summary: if people just want to send some messages to other users, let th= em do=20 so whatever way they want, be it kopete, psi, kit, ... But in the very moment we want to use the possibilities of this technolog= y, a=20 cross-protocol solution based on protocols like ICQ or MSN is a bad choic= e=20 and will yield trouble, since it was not designed for what we want to do.= And=20 setting up an account is not the pain some people suggested. OTOH, if this SIMPLE protocol is what it sounds to be, then it may make s= ense=20 to support that one some day, since it sounds as if jabber and SIMPLE sha= re a=20 lot of functionality. But a good quality jabber lib is here today,=20 well-tested, stable, while I think there is nothing for SIMPLE. And from = the=20 resons pointed out above, any other protocol is not really suitable for u= sage=20 besides simple chatting. (and libpsi will use KDE soon, I am sure, otherwise what point would be=20 putting it in kdenonbeta) One thing though, I think libpsi (even when renamed to a generic name) sh= ould=20 go into kdenetwork for the time being, since I believe no one can predict= the=20 requirements for an abstract IM API, using IM for things other than plain= =20 chatting is too new. When common requirements crystallize, maybe someone = did=20 a SIMPLE lib, and then an abstract API can be created for kdelibs. Just g= ive=20 it time to develop. CU =09J=F6rg