Re: conversation history

Well, after playing with it, I think what Graham has is probably the 
best that can be done, the parsers require a wrapping tag.

I tried viewing in my web browser (Camino), and while I saw the primary 
text, I didn't see the effects of the font tags, neither the line 
breaks.

Writing the close tag is not such a dire problem as I thought. I 
thought we would have to be closing an arbitrary number of tags, but 
checking for the </log> tag would not be so bad even if in the middle 
of a search. In fact the only thing that I noticed was that there was 
not a space before the close of the <img /> tag, which I thought was 
also required, but at least Camino's parser didn't have a problem with.

--
Robert Hailey


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



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