Mittwoch, 20. Mai 2009
Statische Reihenfolge
Trackbacks
Trackback-URL für diesen Eintrag
Keine Trackbacks
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
Also bei mir lief es bis jetzt immer ohne Probleme (mal abgesehen, dass AOL mal wieder was am Protokoll gemacht hat)
Du meinst Pidgin bzw. Trilian?
Mag ich auch nicht bestreiten, nur ist der hier verwendete Stil wohl ein recht schlechter, da die Spezifikation meines Wissens nach nirgendwo eine statische Reihenfolge vorsieht - dementsprechend sollte man sich auch nicht darauf verlassen, dass es immer so ist.
Zumal AOL den IM_CAPABILITY-TLV nur für "old clients" verwendet. Das klingt ein wenig nach "der könnte mal obsolet werden". Zumindest wird dessen vorhanden sein nicht verlangt - genau so nehmen z.B. Kopete oder auch der Hauseigene ICQ-Client Nachrichten ohne Probleme an, wo Pidgin und Trilian es nicht tun.
Mag ich auch nicht bestreiten, nur ist der hier verwendete Stil wohl ein recht schlechter, da die Spezifikation meines Wissens nach nirgendwo eine statische Reihenfolge vorsieht - dementsprechend sollte man sich auch nicht darauf verlassen, dass es immer so ist.
Zumal AOL den IM_CAPABILITY-TLV nur für "old clients" verwendet. Das klingt ein wenig nach "der könnte mal obsolet werden". Zumindest wird dessen vorhanden sein nicht verlangt - genau so nehmen z.B. Kopete oder auch der Hauseigene ICQ-Client Nachrichten ohne Probleme an, wo Pidgin und Trilian es nicht tun.
so gut wie alle 3rd party clients (ziemlich sicher kopete auch) benutzen libpurple ... also das kopete mal getan hat und der rest nicht war zufall denk ich ... oder sie hatten schon ne neuere version. Jedenfalls is das ein Grund warum man seinen 3rd party client immer schön oft updaten sollte ...
Kopete hat was ganz eigenes. Ich hab vergessen wie es heißt, aber es zeichnet sich u.a. dadurch aus, dass es KDE-like in C++ und nicht wie libpurple Gnome-Like in C geschrieben ist 
Vom Stil her muss ich sagen, dass mir libpurple fast besser gefällt. Bis auf solche Implementierungsbugs eben, aber das hat mit der Lesbarkeit des Codes auch recht wenig zu tun.
Vom Stil her muss ich sagen, dass mir libpurple fast besser gefällt. Bis auf solche Implementierungsbugs eben, aber das hat mit der Lesbarkeit des Codes auch recht wenig zu tun.
Nicht das ich mich jetzt mit dem OSCAR Protokoll irgendwie auskennen würde, aber in der von dir verlinkten Beschreibung steht "These are the tags inside the IM_DATA TLV of an IM channel ICBM; order matters."
Insofern hat libpurble das doch völlig korrekt und du falsch implementiert, oder?
Insofern hat libpurble das doch völlig korrekt und du falsch implementiert, oder?
Damn! 
Das war jetzt ein "self-own", wobei das "should" im RFC-Sinne interpretiert mich rettet.
Das war jetzt ein "self-own", wobei das "should" im RFC-Sinne interpretiert mich rettet.
Suche
Read this blog!
Kategorien
Blog abonnieren
Buttons
Kommentare
Fr, 20.10.2017 13:09
Das heißt dann ja eindeutig, d
ass sie Dein Passwort in Klart
ext speichern.
Ist schon zu
lange her, dass ich mich mit
PPP(oE), CHAP und PAP auseinan
derg [...]
Fr, 20.10.2017 13:05
Ich hatte (Wochen) bevor ich m
einen DSL-Anschlussbrief von 1
&1 bekommen habe im Kundeninte
rface das DSL-Passwort geänder
t.
Im Anschlussbrief war st
and [...]
Mi, 28.06.2017 11:29
Diese Information ist für Inte
ressierte bereits in der Übers
chrift enthalten.
Ich glaub
e nicht, dass es mir obliegt d
en Marktbegleiter durch expliz
ite [...]
Mi, 12.04.2017 00:09
Klarer Fall von "Bootloader ve
rgessen". Oder, fast noch schl
immer: Bootloader so verkorkst
, dass das Update nicht funkti
oniert.
Aber das Ding ist o
hneh [...]