Track previous messages in AIChat, rather than dropping them in AIWebKitMessageViewController

An alternate means of accomplishing the same ends would be reading the transcripts that intersect with the current chat, accumulating the enumerated objects into an array, and keeping the enumerator and array around for some arbitrary timeout, releasing them when time expires to conserve memory.

Can this wait until 1.3 guys?

I think Peter went in the direction he was talking about, and started working on a class to replay chat transcripts. I don't think he's done, but I'd ping him about it :)

So I talked to Peter, and his class wouldn't work for situations where you don't have logs.

I didn't think it was right to keep a "cache" which is actually just a log, just in a different directory with different file extension, since if you've disabled logs you probably don't want them on disk either.

So I'm going to write a cache for this. On cache miss, if you have logs enabled, we'll get those, otherwise fail.

I'm thinking the cache eviction strategy should be:

• When the cache grows to more than ~5-10MB (formal definition will probably be in terms of number of elements) globally (across all AIChats), older objects will be evicted.
• All objects for closed windows will be evicted.

Thoughts on this?

It would also be nice to hook up scrollback such that old messages get evicted too, limiting you only to cache if you have logging off, and giving you infinite scrollback (i.e. from the beginning of time) if you have logging on. (note that the loads would happen asynchronously).

See #8088

See also #367

Replying to cbarrett:

So I'm going to write a cache for this. On cache miss, if you have logs enabled, we'll get those, otherwise fail.

If we're logging, I think we shouldn't use the cache at all. It is -not- a common activity for most users to utilize applescript to look at previous messages; I don't think we should increase our already not-insignificant memory footprint by keeping in memory data we've written to disk to save a small disk access performance hit for a minority of users.

Colin, what's our status on this? Do you want to do it in the 'soon' timeframe, or should we shift it to a later milestone?

We should move this to 1.3, this can wait. Might be able to get it done before then, but it's not gonna block the release

Replying to evands:

If we're logging, I think we shouldn't use the cache at all. It is -not- a common activity for most users to utilize applescript to look at previous messages;

What about dynamically switching between unencrypted logged chatting and encrypted and therefore not logged chatting?

Then there is a mention of dynamically switching between styles which could, if implemented as a per tab/window/contact setting, be a common activity. Just a thought...

Replying to evands:

Replying to cbarrett:

So I'm going to write a cache for this. On cache miss, if you have logs enabled, we'll get those, otherwise fail.

If we're logging, I think we shouldn't use the cache at all. It is -not- a common activity for most users to utilize applescript to look at previous messages; I don't think we should increase our already not-insignificant memory footprint by keeping in memory data we've written to disk to save a small disk access performance hit for a minority of users.

I disagree. First, having a rather large codepath like this that is just not used on pretty much every developer's machine is asking for trouble. Secondly keeping AIContentObjects is useful for a lot of things other than just this one applescript command. It could be used to actually increase performance by removing items from the WKMV and inserting the only when the user scrolls up, via AJAX techniques.

Thirdly, if the memory footprint hit isn't acceptable for people using logging, why is it acceptable for people not using logging? The cache will limit the global number of objects in it, so the footprint hit will be a known quantity (only a few MB).

Replying to cbarrett:

First, having a rather large codepath like this that is just not used on pretty much every developer's machine is asking for trouble.

I meant that no Adium developer runs with logs off. Not that we should only have code used by everyone.

Looking back on old-Evan's comments, I think I was overestimating the memory impact of a sanely written cache. Evict after a sane number of entries, use logs on a cache miss if logging is enabled, and do our thing :) We really shouldn't be talking about massive memory usage since we'll have an eviction policy, unlike the old implementation which kept around every message's AIContentObject even if the chat had hundreds of messages.

This could be a little weird for AS, I think. It becomes "get some arbitrary number of past messages for this chat" rather than "get the past messages for this chat".

Replying to Catfish_Man:

This could be a little weird for AS, I think. It becomes "get some arbitrary number of past messages for this chat" rather than "get the past messages for this chat".

Yeah... with logging off, we'd have no way of keeping messages around without them being in memory.

Could we do a DOM parse to pull messages back out of an open webkit chat window?

Not without making a non-backwards compatible change to the message style format. The current format provides extremely few guarantees about the structure of the page. One top-level element per message would help a lot, but dealing with consecutive messages, and determining which elements corresponded to which bits of data would still be tricky.

Punting again, whee.