Mercurial > pidgin
changeset 11451:99548d90257e
[gaim-migrate @ 13690]
Documenting my revised thoughts about logging for unnamed chats.
committer: Tailor Script <tailor@pidgin.im>
| author | Richard Laager <rlaager@wiktel.com> |
|---|---|
| date | Mon, 05 Sep 2005 23:44:26 +0000 |
| parents | b7978afe81d0 |
| children | 7e671f619c3c |
| files | TODO |
| diffstat | 1 files changed, 10 insertions(+), 16 deletions(-) [+] |
line wrap: on
line diff
--- a/TODO Mon Sep 05 08:14:10 2005 +0000 +++ b/TODO Mon Sep 05 23:44:26 2005 +0000 @@ -2,6 +2,7 @@ * 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 @@ -10,22 +11,15 @@ * (12:58:39) Robot101: user list always|auto|never * topic only where supported by the protocol * how do we log this? {{{ - * rlaager's proposal: {{{ - * the goal of logging is to be able to find something again. - * you expect to see the logs for a person IFF they are in that conversation - * you don't really need to see the log of a chat before or after said person joined it - *if you did, you'd be looking at some other person(s)'s log - * so: - * each conversation has 1 or more logs associated with it. - * when someone joins, a new log is opened to log everything that happens in the - conversation, but to that person's logs. - * when someone parts, that one persons' log is closed - * this causes some duplication, the way to avoid this would be to close everyone's - log on a join/part and use a new file. we could then use links of some sort (hard - or soft) to "put" that one file in each user's directory. but this would - needlessly split the logs of someone who had been there all along. I think this - duplication is acceptable. - * this would not solve the problem of chats with the same name as a buddy. + * 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 }}} }}} }}}