Re: conversation history

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

On Mar 24, 2004, at 2:49 PM, Graham Booker wrote:

> It is times like this that I wish everyone on this list could program 
> and would submit patches.  There are a lot of good ideas here, but the 
> issue is lack of time on part of the developers.  See my responses 
> below:
>
>
> On Mar 24, 2004, at 10:22 AM, Jeffry Engert wrote:
>
>>
>> On Mar 24, 2004, at 9:53 AM, Jeremiah Blatz wrote:
>>
>>> So, my vote for any changes to the stored convo format would be 
>>> something like this:
>>> * Make the file name end in .html
>>> * Make there be no spaces in the file names, so as to ease 
>>> integration with xargs
>>> * Perhaps wrap each message in the convo with something like a 
>>> <firemessage></firemessage> tag, and maybe even include a header 
>>> like <fireconvo date=xxxx ....> to include some more metadata 
>>> without interfering with web browser friendliness.
>>>
>>> Jer
>>
>
> This seems a bit similar to what I want to change to in a future 
> version.  Basically, I was thinking saving as xhtml (html that is xml 
> compatible).  Essentially, it will be an XML file that uses html tags. 
>  Now there will be additional tags surrounding the message portion 
> quite similar to what you had above.  Currently I am looking at 
> <message received="YYYY-MM-DD HH:MM:SS ±HHMM" translated="yes">blah 
> blah <font color="#ff0000">blah</font></message>.  I may have some of 
> the tags slightly wrong, but you get the idea.  Of course, translated 
> will only be there if it really was translated.  I am going to need 
> something like this for what I am planning to do in the near future.  
> Fire will read this as an XML file, and parse the XML, but browsers 
> will see it as html, so a .html may be the best option.  The XML will 
> be in a nice format, so, you could take the XML, run it through an 
> XSLT, and then create custom HTML that can be displayed nice a pretty 
> using a CSS.  I guess I should create a DTD at some point and let you 
> guys comment on it.  Enough acronyms for you?
>
> The question I have for you all is the following:  How should the 
> display logs appear when you display it within a web browser?  Should 
> they appear as they do now, or should it look different?  Nothing 
> complex here, this is after all just if you don't want to see the logs 
> in Fire.  Complexity can be done with the process I described above.
>
> The key issue is going to be figuring out how to append to an existing 
> file since XML parsers will throw an error if you don't close all 
> tags, and inserts must be done inside some of the outer tags.  It is a 
> problem I am trying to consider.  Anyone has any ideas, go ahead and 
> suggest them.  At the moment, I am considering not closing the tags in 
> the files, and append the closed tags to the string of the file upon 
> read, or re-writing the file each time.  Doing something like a fseek, 
> and then writing may not be a bad idea, but I will have to see.
>
>
> Submit ideas now, or don't complain when I finish ;)  This is a ways 
> off (post 1.0), but I will be tearing aport code soon.  You will see 
> the fruits of my last code shred really soon.
>
>> Some things I'd like to have
>>
>> * save to rtf for friends
>
> File -> Save Current Chat.  Has been there for a while
>
>> * always log by name, ignore alias
>
> Assuming you mean screenname, 1.0 does this.
>
>> * or group by alias regardless of service they are chatting on
>
> 1.0's stored IM Controller converts (internally) screen names to the 
> current alias, and sorts by that.
>
>> * search by time constraints
>>
>
> Sounds like a good idea, but once again, time constraints kill.
>
>> also, am I the only user that has problems with conversations going 
>> on two files because you closed the window too soon, or visa-versa? I 
>> don't think there is much that can be done about this... just 
>> dreaming I guess
>>



-------------------------------------------------------
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_id70&alloc_id638&op=click