Re: conversation history

OK, I am thinking about changing this yet again.  Basically, I am 
cutting out the formatting surrounding the sender tag since it is 
redundant and may cause a few problems if the formatting is changed.  
Note the img tag is gone because it can be gotten by the name of the 
event tag.  I will make this the case for everything that put images 
badges in the display.  Such images will show up in the logViewer but 
there is no point to logging them when a simple property is smaller and 
does the same job.  You won't see the timestamp if you open in a web 
browser, but if you really need to see it, view the source.  Mustn't 
forget that the primary purpose of this is to save the data for fire.  
HTML viewing is just a plus, and this still views fine.

I don't think that "sep" is an html tag, is it?  If it is, I should 
change it to something that isn't.

I am well aware that the events may look strange in a web browser 
"meetoo has join thischatmeetoo" but I can't see any easy way around 
it.  I would like it to not show up, but the tag must be there in that 
position in exactly that manner to maintain compatibility.  Maybe I 
could but a <br /> before it?  Whatever is done, it can't be contained 
within another tag.  Trust me, I have a REALLY GOOD REASON for this.  
Only Event objects will be affected in this manner.

Comments?  Anyone like this?  Anyone hate this?

Example:
<?xml version="1.0"?>
<log began="2004-03-29 21:21:15 -0600">
   <event id="0" occurred="2004-03-29 21:21:25 -0600" 
name="memberJoined">
     <sender>irc</sender>
     <sep>: </sep>
     <message service="yes">
       <font color="#555555" style="background-color: #ffffff; 
font-size: 10">metoo has joined thischat</font>
     </message>
     <name>meetoo</name>
   </event>
   <br />
   <envelope id="1">
     <sender>metoo</sender>
     <sep>: </sep>
     <message received="2004-03-29 21:21:34 -0600">
       <font style="font-size: 10">Yo </font>
     </message>
   </envelope>
   <br />
   <envelope id="2">
     <sender self="yes">Me</sender>
     <sep>: </sep>
     <message received="2004-03-29 21:21:38 -0600">
       <font color="#0000d5" style="font-size: 10">Hey</font>
     </message>
     <br />
     <message received="2004-03-29 21:21:41 -0600">
       <font color="#0000d5" style="font-size: 10">How is it 
going?</font>
     </message>
   </envelope>
</log>


------------------------------------------------------------------
Graham Booker                   Texas A&M University
[email protected]    Graduate Student in ELEN
------------------------------------------------------------------
On Mar 27, 2004, at 1:49 PM, Graham Booker wrote:

> 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
>>
>