Re: conversation history

Yeah, I was about to say I think XML requires a single root element.  
Actually, the img tag is correct in the code (has the space before the 
/>), but I modified it in the version I pasted here because it was <img 
src="file:///....." /> and that will not be the logging format.  I just 
haven't gotten around to fixing the logging yet.  Writing is easy, but 
reading isn't.  Maybe I will have to resort to making my own HTML 
parser.


------------------------------------------------------------------
Graham Booker                   Texas A&M University
[email protected]    Graduate Student in ELEN
------------------------------------------------------------------
On Mar 28, 2004, at 9:13 PM, Robert Hailey wrote:

> 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
> _______________________________________________
> fire-development mailing list
> fire-development-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/fire-development
>