Re: conversation history

OK, here is a format that I was thinking about.  This is an example irc 
conversation where meetoo joins the room, thischat, and says "Hey".  
The response is "Yo" followed by a "How is it going?"  (Indented to 
look prettier)

<?xml version="1.0"?>
<log began="2004-03-26 22:04:30 -0600">
     <event id="0" occurred="2004-03-26 22:04:39 -0600">
         <font color="#00ff00" style="background-color: #ffffff 
;font-size: 11"><b>
             <sender>irc</sender>
             <timestamp> (10:04:37 PM): </timestamp>
         </b></font>
         <message service="yes">
             <img internalName="LoggedOn_small.tiff"/>
             <font color="#555555" style="background-color: #ffffff; 
font-size: 10">meetoo has joined thischat</font>
         </message>
     </event>
     <br />
     <envelope id="1">
         <font color="#0000ff" style="background-color: #ffffff; 
font-size: 11"><b>
             <sender>meetoo</sender>
             <timestamp> (10:04:48 PM): </timestamp>
         </b></font>
         <message received="2004-03-26 22:04:50 -0600">
             <font style="font-size: 10">Hey</font>
         </message>
     </envelope>
     <br />
     <envelope id="2">
         <font color="#ff0000" style="background-color: #ffffff; 
font-size: 11"><b>
             <sender self="yes">Me</sender>
             <timestamp> (10:04:52 PM): </timestamp>
         </b></font>
         <message received="2004-03-26 22:04:54 -0600">
             <font color="#0000d5" style="font-size: 10">Yo</font>
         </message>
        <br />
         <message received="2004-03-26 22:05:02 -0600">
             <font color="#0000d5" style="font-size: 10">How is it 
going?</font>
         </message>
     </envelope>
</log>

Now, the real thing is not well formatted, but rammed together.  This 
log is 1147 bytes on disk.  This should contain all the information 
that we could possibly need.  This will not only display in a web 
browser, but will display well as it is using proper html for 
background color and font-size (at least as far as I know html, any 
comments?).  This is also a valid XML file (It was all generated by a 
modified version of Fire).

It also looks really nice in Safari.

I am thinking about doing the following for saving:  Open the file, 
fseek to the end (mines 7 or 18 (depending on if this is from the same 
sender as the last) bytes or so), write, close.  This is fairly safe, 
and fire could try to repair on a failure induced by a system crash (by 
simply closing tags left open).

------------------------------------------------------------------
Graham Booker                   Texas A&M University
[email protected]    Graduate Student in ELEN
------------------------------------------------------------------
On Mar 25, 2004, at 10:16 AM, Robert Hailey wrote:

> At first, I thought that changing the log format at this time is not 
> really worth the effort. Web browsers can most likely be 'trained' to 
> read a fire file if that is what you want, the same way other plugin 
> file types are done. And if a major benefit to converting to xml would 
> be ability to convert it to HTML, converting the current format to 
> proper HTML (for viewing not in real time for storage) I would think 
> to be trivial.
>
> However, if we change log formats the ability to store extra metadata 
> in a usable way (like for a time constraint search) is a really 
> valuable benefit. Jeremy's idea is probably the best quick patch (to 
> encode it in inert html tags).
>
> Speaking to Graham's idea, being able to store logs in xhtml would 
> probably be the ultimate solution... If we didn't want to write the 
> logs a single line at a time, which I really think we should try and 
> stick to. If we try and always write a complete xhtml file, there will 
> surely be times when the program fails; not only in development 
> environments (like breaking the program in debugging), but in the real 
> world (like if the clients computer goes to sleep and never wakes up). 
> That condition is unavoidable, but I claim that the log files 
> certainly must be stored in a consistent manner. If we claim that the 
> logs should be xml parsable, they all should be.
>
> I see three ways that the issue can be resolved.
>
> The first would be to not store any of the log files in xhtml, as 
> there would surely be some files that will not be proper xhtml, and if 
> necessary provide a simple means to generate a proper xhtml file. Even 
> if it means storing the logs in xhtml minus the closing tags, they all 
> should be done that way. A make file, or fire command could even be 
> made to easily convert them (e.g. cat ${file}.xhtm_ trailer.sub >  
> ${file}.xhtml). If this is done, then the log mechanism will not be 
> significantly different at all; even if we store it as we do now, use 
> a psuedo-xhtml, or has anyone thought about storing logs in LaTeX ?
>
> A second way would be to validate the log files on fire's startup. We 
> could then have valid xhtml logs, but the program would have to make 
> sure that they are consistent. Checking the most recent log in each 
> subdirectory and repairing it if necessary. Anyone want to code this?
>
> A third way is a mix of the above two, and that is to have parallel 
> log files (e.g. *.session3 and *.xhtml files). Then we could always 
> write the xml file at the closing of a session3 file and never have an 
> xhtml file that is invalid while maintaining line item writing of 
> session files. To have fire utilize the preexisting utilities to parse 
> xhtml files, before it does a search that would require them, it 
> generates the xhtml files that are not already there. Notice that not 
> writing the file until the close is important so that fire does not 
> have to worry about 'updating' xhtml files. But there could still be 
> an option in the 'complex' search dialog to rebuild these files.
>
> --
> Robert Hailey
>