On Thu, 18 Aug 2011 22:12:36 +0200, Jonathan Schleifer <[email protected]> wrote: > Actually, exactly the opposite is the case, if you look at the > commit. There was a lot of code, but libotr just wants to be that > three-line drop in, so you lose a lot of flexibility which you need to > properly support XMPP with all it's features.
out of curiosity, what are examples of those XMPP features? > I'm especially astonished to hear that it works in bitlbee without any > effort, as there is no HTML parsing in bitlbee. Or is the > implementation for bitlbee one of those where you suddenly see HTML as > soon as something goes wrong? i'd say it was without much *undue* effort. as for the HTML messages, there is agreement i think that these are the big ugly part of libotr that needs overhaul. however: there is code in bitlbee to display HTML messages, because that's what you get from some transports. so we push OTR's messages through that and display them. what kind of cases did you encounter where you had to actually parse the message to determine an error? -pesco PS. i apologize if my original comment came off as condescending. apparently, as Kjell explained, a lot of the trouble had to do with the C API being hard to interface into the Python world. i thought the developer had just been lazy and annoyed when it became clear you need to handle a bunch of stuff for this encryption shit. that was arrogant. sorry. _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
