Re: Re: conversation history

On 3 Apr, 2004, at 23:19, Graham Booker wrote:

> We have had requests lately to change the logging format into a more 
> XML based format.  At the same time, I had started work on some things 
> that would require a slightly more advanced logging format, and XML 
> will fit nicely.  Another concurrent request was to clean up the 
> "html" (it is actually AIM's bastardized html) in the current logging 
> format so that it renders better in a web browser.

And I, being all old-skool and stuff (not really) prefer pure text. Of 
course, HTML is better since then you can é, so you don't have 
to worry about color codes and character sets (I'm speaking from an IRC 
perspective).

While I like XML, it's bloaty and also a pain to grep (unless you write 
a log parser, which I'm rarely in the mood to do). Proteus' old logs 
were XML (a property list, IIRC), which were a pain to read (in less), 
and a pain to search (since the sender and stuff is on a separate 
line).

For an analogy, I like Java, but it's bloaty and slow (but it's not as 
bloaty as OSX's packages!).

Proteus then switched to some DB format, which was even worse, since 
the only thing that could parse it was Proteus, which sucked up around 
100 MB to parse 12 MB of logs (usually I closed the window at around 
70/80, which stayed in use until I quit proteus). After switching to 
Fire, I downloaded the source to whatever DB engine they used and 
exported the SQL. I've yet to code something to split it into multiple 
files (I started around last year?).

That said, the purpose of logs can be split into two things (I think 
system designers call these specifications):
1. To record what happens.
2. To refer to later.

To do this properly, there are a few requirements (I think they call 
these design parameters):
1a. The format must be unambiguous.
1b. Everything must be recorded (if the user so desires).
1c. The format must be extendable.
2a. The format must be easy to read (e.g. with less).
2b. The format must be easy to parse (with whatever log parser).
2c. The format must be easy to search (e.g. with grep).

We also probably want it to be opensourcey. This limits us to XML, 
HTML, or text. Since we want it to be both unambiguous and extendable, 
we're stuck with XML, unless anyone wants to make up the world's 
weirdest text format, or HTML with comments/weird attributes/whatever.

Read: XML may be icky, but it's unfortunately the best there is.

I'll make a few suggestions:
A. Add newlines in appropriate places (after each envelope/event) to 
make grep easier.
B. Save the ID of the user, e.g. <sender 
id="[email protected]">meetoo</sender> (or screen name/number/email 
address as appropriate). For a direct connection (e.g. DCC or 
whatever), also ip="1.2.3.4".
C. Save the ID of the service, e.g. <log began="2004-04-02 22:01:57 
-0600" protocol="irc" server="irc.nowhere.net"> (or 
icq/icq.mirabilis.com, etc).

The following also apply to chat windows:
D. Save the (server-side) nickname of the user (to track nick 
changes/MSN nicknames/etc), since it's often more than just a nickname 
(some people put poems there).
E. Save all status changes (e.g. away messages for IRC).
F. Save file transfer requests.
G. Save "You have been disconnected" rather than "metoo is offline".

Is there any way to display the attributes? (e.g. so you can read dates 
in a web browser)

This has been a little more ranty than I intended. Oops.

Perhaps I should subscribe to fire-dev.

- Purr



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Fire-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fire-talk
Have a question? Please read the Fire Frequently Asked Questions:
http://fire.sourceforge.net/faq.shtml