Mercurial > pidgin
view TODO @ 13662:b198d0c26b83
[gaim-migrate @ 16064]
Fix Coverity CID 26: A potential crash when the server sends us
an incoming channel 2 ICBM of the ICQ server relay type but
does not send the data normally associated with such an ICBM.
This should never happen.
Fix Coverity CID 45: A potential crash when the server sends us
an incoming channel 2 ICBM but does not send the data normally
associated with such an ICBM. This should never happen.
Fix Coverity CID 47: A 1 byte memleak when signing on using the old
blist method and not when using SSI. This never happens. As far
as I can tell it has been like this since the beginning of time.
It's a weird memleak.
Fix Coverity CID 57: A memleak of the length of a screen name when
searching for screen names by email address and the server returns
a malformed SNAC. This should never happen.
Fix Coverity CID 59: A memleak of the length of an ICBM when _parsing_
an outgoing ICBM. I don't believe this ever happens, and I suspect
the code exists from a time when libfaim was perhaps being written
so that it could be used in an AIM server (in addition to just a client).
I should probably remove the function.
Fix Coverity CID 132: A memleak of the length of the email address
when searching for screen names by email address.
Fix Coverity CID 146: Check the return value of read() and print
a warning to the debug window. This code is only used when AOL
enables their crazy AIM executable hash value stuff, which hasn't
happened in 5 years or so.
Fix Coverity CID 191: Comment out some code that isn't used.
Fix Coverity CID 192: Get rid of a harmless assignment to a variable
that wasn't used.
Fix Coverity CID 194: Comment out some variables and code that
isn't used.
Fix Coverity CID 198: Get rid of a variable that wasn't used in
gaim_ssi_parselist().
committer: Tailor Script <tailor@pidgin.im>
author | Mark Doliner <mark@kingant.net> |
---|---|
date | Wed, 19 Apr 2006 03:31:47 +0000 |
parents | 4b5822e48b53 |
children | 361c15e0b320 |
line wrap: on
line source
* conversation api {{{ * need to handle: {{{ * unnamed chats * chats with the same name as a buddy * this should be working now, but it needs to be kept in mind when (re-)designing * jabber Messages (one off messages vrs a conversation with a backlog) * multiple conversations with a single buddy (jabber, with thread tag) * bugs }}} * notes: {{{ * (12:58:39) Robot101: user list always|auto|never * topic only where supported by the protocol * how do we log this? {{{ * rlaager's (NEW) proposal: {{{ * each conversation has 1 or more logs associated with it. * when someone joins, a new log is opened * file based loggers should try to use hard-links in a smart way to avoid duplicating data on disk as much as possible... * this needs to be designed in such a way that a database logger can handle it w/o duplication... * TO SOLVE THESE CONCERNS, a link and/or copy function callback will likely need to be added }}} }}} }}} }}} * buddy list {{{ * we have not committed any gobjectification, so this is not a blocker for 2.0.0 until we do. * if we do, it is only a blocker to the extent that gaim needs to run. That is, we do not *necessarily* have to gobjectifiy everything as long as we preserve functionality. * That being said, my understanding of the signals mess says that it is probly more work to try to do this in stages than to start it or not start it. * This would require some sort of signal aggregation, as gobject signals are unique to the instance. * one way to do this would be to emit the signals from a non-descript buddy object. this would most closely mimic the current functionality * a second way would be to actually try to aggregate them in some way. I really don't know how possible this is, but it would allow us to do things like set a pounce on everyone in a group or define sounds on a per-group basis. * we could look at replacing the UI ops with signals/call backs * bugs * wrong buddy given priority }}} * build targets {{{ * this is not a blocker * we need build targets for libgaim, we need to test them, and make sure they work. * we ought to use our own build targets to build the executable itself. * due to the limitations of cvs, this cannot accompany moving files to other directories at this time. }}} * status {{{ * Error messages aren't particularly usable currently. we need to be able to see the full text of the error, and what account is in that error condition. * No way to see accounts not in the global state. * Easier access to saved states is needed. }}} * Privacy {{{ * this is not a blocker for 2.0.0 * Privacy sucks. it doesn't handle many of the protocols in a way that users understand. notably msn, but also yahoo, jabber, and icq. * We want to sync to the server as much as possible, entirely local-only privacy is not an option except on protocols like irc that have no server-side. * We want to be as consistent across protocols as possible. this will require renaming things on some protocols. * Bleeter suggests that we create a privacy.xml, remove privacy from blist.xml. He suggests that each protocol define certain capabilities & defaults, with accounts.xml holding exceptions to the defaults. }}} * Perl {{{ * Block for 2.0.0 or remove perl: * Extended testing and resolving the inevitable bugs remains. * Test each call to make sure it actually works * Make it work with G_MODULE_BIND_LOCAL }}} * Prefs {{{ * on upgrade from 1.x, the timestamp preference often gets lost. }}} * system log {{{ * The system log minimally should tell me what _I_ do in gaim. It should (minimally) tell me about my accounts and actions. It should thus list * gaim start and quit * Account connection * account disconnection, and reason if caused by error. * account state changes, IFF we are logging that for buddies. * This might include the state message(s). * This might be done using one or more files. * historically, the system log has also functioned to log things about buddies that do not relate to a specific conversation. While I(luke) do not at all object to this, it could be argued that such functionality more properly belongs in a plugin, such as the buddy state notification plugin. if we continue to implement such functionality, it could include: * logging when a buddy signs on, including in some form what account sees that change. * logging when a buddy signs off, including in some form what account sees that change. * " " " " goes idle, " " " " " " " " " * " " " " goes away, " " " " " " " " " * " " " " becomes available, " " " " " " " " " * like the logging of my own accounts, this could be done in one or more files. * one potential downside of using multiple files is the idea that either the file's contents duplicate information contained in the file's location/name, or that we need to manipulate the display so as to convey that information to the user from the graphical viewer }}}