OLPC branch feedback
debug.c: I don't like the capital letter debug flag
conn-aliasing.c; setaliases_foreach: do a send_with_reply even if the callback just prints a warning if there's an error
gabble-connection.c: XXX: this should be generated... generate it then?
connection_msg_callback: this is at least poorly named, or it should actually live outside the connection in a conn-pep.c of some description. it also has the side-effect of swallowing all messages whose first <event> contains no XMLNS... use early return for null event_ns and wrong prefix, which will avoid nested ifs too. also it calls tp_handle_unref in the path where it's already known to be 0 (odd spacing there too).
olpc.c/h: missing copyright headers. should this not be conn-olpc.c anyway?
global hash tables? nyet. store these per connection and free them when we disconnect. secondly, the contacts_activities hash table is indexed by handle but not within the context of a given connection, which is totally wrong. as mentioned on channel, members of gabble connection, or qdata would be better.
typedef'd structs should be CamelCase, and you can make an anonymous typedef anyway (typedef struct { ... } ActivityInfo).
activity_info_new: use slice_new0 to avoid unexplained madness in future. odd spacing of * in prototype. why dup the string version of the room if you have the handle and the repo? you can always look it up. the activities_info hash could then be indexed by handle, saving memory and strcmps.
function prototypes in this file are inconsistent, see update_activities_properties vs activity_info_new vs activity_info_set_properties (which is correct gabble style)
inspect_contact should call _is_valid which will can return an error for you too; inspecting an invalid handle is a shooting offence
check_publish_reply_msg: we have NODE_DEBUG to print a node, but its rarely worth using at all, because you can always run with LM_DEBUG=net to find out the reason for errors. maybe use some xmpp_error stuff here to print just a reason string. ditto check_query_reply_msg.
extract properties: make an early return if props_node is null. in the bytes bit it leaks the decoded GString, then leaks the GArray too. use _take_boxed. is it really sane to assume a NULL type is bytes, and is base64_decode safe against NULL value? maybe just skip anything where type and value are unset.