Questions about the new log format

[Catfish_Man]

No, the default is 5 lines because adding messages to the webkit view is slow.

Wait wait wait. Shenanigans! Why would you have to add them individually? Just recreate the HTML as it was during the last session and pipe it into WebKit on creation of the object instance.

In addition to Catfish_Man's point, note that this would require message history to be tied to message styles -- change your style and your history shows up with HTML formatting from that previous style?

Likely we'd specify the html for the messages, and the styles would be just that: stylesheets. csszengarden.com gives an example of how powerful this approach can be.

[m_beckman]

But if the new xml-logs by default will be opened in the Adium log viewer, isn't it more important how the log viewer shows the logs, then if there is a new log file at midnight or not? If the log viewer lets the user follow logs from one logfile to another, does it matter if there is a new file at midnight?

If the log viewer lets me follow the logs of one of my meta contacts independent of protocol and without exploding if I try to read a log that spans over several logfiles, then I couldn't care less if there is a new file at midnight or not. Let the devs decide how to store the log files as long as they make a good log viewer.

[Catfish_Man]

Let the devs decide how to store the log files as long as they make a good log viewer.

That is, in fact, what this thread is about

Personally, I vote for one log file per day, for spotlight reasons.

[Ringo]

In addition to Catfish_Man's point, note that this would require message history to be tied to message styles -- change your style and your history shows up with HTML formatting from that previous style?

I never suggested doing that, Catfish_Man misunderstood me.

Just recreate the HTML as it was during the last session and pipe it into WebKit on creation of the object instance.

I was suggesting using the log files to create it from scratch, then send that directly to the WebKit object. I'm actually a bit surprised that's not how it's done now.

[evands]

I never suggested doing that, Catfish_Man misunderstood me.

Fair enough, glad we're on the same page now.

Just recreate the HTML as it was during the last session and pipe it into WebKit on creation of the object instance.

I was suggesting using the log files to create it from scratch, then send that directly to the WebKit object. I'm actually a bit surprised that's not how it's done now.

In a sense that is what's done with every message, history or not. Catfish_man is going to be looking at how to use the DOM system more effectively, but right now elements have to be added one at a time; it's not slow on the order of 5 to 10 items, but adding an entire conversation would lag opening chats unacceptably (keep in mind that 'unacceptable' is anything more than 0.5 seconds or so) as the message-specific HTML was built and sent to the webview.

Of course, that could be slow because it's not written as well as it could be. While I don't think in any case that it is desirable to insert an entire old conversation into the chat, we'd welcome any efficiency an interested coder could add... and a full-chat history plugin wouldn't be outside the realm of programmability by any means considering that history is supplied from a class outside the message view class at present.

[Ringo]

You appear to be discussing the 'division into separate log files' mainly as a question of GUI usability. (Apart from the mentioned disadvantages of having huge/many files.) But is that really the main concern? Does the 'log file implementation details' even need to be exposed to the end user in such a direct way? Shouldn't the larger question be how we want to present the combined log data to the user?

Sorry about the short reply before.

The main concern? No. But I does fit with the 80/20 rule. Right now logging doesn't work. It doesn't work because it people don't gush about it on VersionTracker. The entire purpose of moving to XML logging is to fix the drawbacks of the current implementation. If the entire logging system needs to be replaced, why not take advantage of the situation and make it a little better?

Logging doesn't normally cross over with usability. Logs are almost never intended for end-users. But here we are, and the rules are different.

As I've mentioned a few times now, when the time rolls past midnight a new file is created. This is a 100% arbitrary method to prevent log files from becoming too large. When searching in the log viewer any conversations that spanned a midnight show up as two separate entries. The only way to display this correctly would be for the log viewer to notice the lack of a window closed event tag and assume that the next file is still part of the same conversation. Fine, right?

What if the next file is deleted, renamed or moved?

What about spotlight? Let's say you had a conversation about Adium. There would probably be mentions of that word in both files. Why should the same conversation appear twice when searching for "Adium"?

You may not think this is important, but logs need to be accurate. That is their purpose. Logging human conversations requires more context than logging http accesses. The only way I see to handle this properly is to have the log files directly reflect conversations.

These aren't web access logs, they're conversations, and they need to be treated as such. I'll do anything I can to help make this happen because I want Adium to be the best thing out there.

[evands]

Ringo is making an excellent point about multiple entries -- a spotlight search that hits a single 'conversation', whatever that means, would seem to be malfunctioning to a user if it returned two separate log files... that might be the least of all evils, though.

I'm going to debate with myself for a post.

What if we continued to do one log per day except in this edge case of a conversation crossing the midnight barrier? If I'm talking on Monday, and the conversation continues into Tuesday morning, keep logging to the log for Monday until I close the window, at which point the next time I chat on Tuesday (even if it's five minutes later) we're on the Tuesday log. That would ensure that conversations show up as single entities when searching...

except now we have a problem for Joe User who leaves the window open all the time. If the window is open for a week, every conversation from that week ends up within the log file for Monday. That's no good.

[Ringo]

In a sense that is what's done with every message, history or not. Catfish_man is going to be looking at how to use the DOM system more effectively, but right now elements have to be added one at a time; it's not slow on the order of 5 to 10 items, but adding an entire conversation would lag opening chats unacceptably (keep in mind that 'unacceptable' is anything more than 0.5 seconds or so) as the message-specific HTML was built and sent to the webview.

What I'm talking about doesn't involve the DOM at all, though. I'm saying to parse the log file and recreate the base of the message view outside WebKit. Then when the message view is created, pass the entire source to it and let it render. I can't imagine this could possibly be slow. I use PHP and Safari on a daily basis to do things far more complicated than this using far less efficient tools and methods and it is not slow in any way.

Of course, that could be slow because it's not written as well as it could be. While I don't think in any case that it is desirable to insert an entire old conversation into the chat, we'd welcome any efficiency an interested coder could add... and a full-chat history plugin wouldn't be outside the realm of programmability by any means considering that history is supplied from a class outside the message view class at present.

I'm not talking about old conversations or full history either. I'm only talking about a conversation that is likely so recent that it would likely be the same conversation.

The logging object instance would only have to pass the parsed data to the message view object instance. A method in the message view class could reuse the same methods that build the individual messages, but rather than sending it to WebKit via the DOM voodoo as it is now, it builds the entire source and sends it directly to the WebKit instance when it is created. From that point on use the normal methods to tack on new messages.

[cbarrett]

The advantage, implementation-wise, of per-window-open log files is that you don't have to resume writing to them (which means re-parsing parts of the XML file, to restore the state of the state-machine my quick appending code uses).

It's not a huge deal though, either way. I'd just like to have some sort of consensus reached before proceeding.

[evands]

The advantage, implementation-wise, of per-window-open log files is that you don't have to resume writing to them (which means re-parsing parts of the XML file, to restore the state of the state-machine my quick appending code uses).

It's not a huge deal though, either way. I'd just like to have some sort of consensus reached before proceeding.

I think per-window open isn't something anyone is advocating... it just has too great a potential to become a giant mess in terms of the number of files that might be associated with a single functional chat.

Besides the debatable advantage for Spotlight searches (Ringo makes a goo d point about the surface-oddity of a single conversation showing up twice), there's no functional difference between splitting every 24 hours and splitting "whenever a conversation has been inactive for X hours" -- especially since that nearly never happens given that we log status changes. Furthermore, that turns out to be a minor implementation detail...

The context-based message history you're describing, Ringo, doesn't seem to be any different than what's currently in existance (in terms of the user's perspective) except that you want an explicit preference to determine whether the displayed history appears 'historical' or 'current'. There's no need to do an either/or between that enhancement request and the logging format.

[Ringo]

except now we have a problem for Joe User who leaves the window open all the time. If the window is open for a week, every conversation from that week ends up within the log file for Monday. That's no good.

Agreed! Excellent point. I'm often one of those people. Any per-window-open implementation would suffer from this problem. A timeout implementation would not suffer either from that or from passing midnight.

[Ringo]

So is there any consensus here?

[The_Tick]

I say we do midnight. We know it, we work with it now, and we know the problems with it.

[bgannin]

I say we do midnight. We know it, we work with it now, and we know the problems with it.

Certainly seems to be the consensus

[Ringo]

I say we do midnight. We know it, we work with it now, and we know the problems with it.

Certainly seems to be the consensus :)

Not from me. I find the search result split to be a fairly serious issue.

[bgannin]

Consensus: (definition 1) - general agreement

Note: TOTAL is not contained therein.

Your dissent has been dually noted and discussed, as the last several pages are a testament.