[ts-gen] Ugo's post; was a blank subject line

[R P Herrold]

On Fri, 28 Sep 2007, a off list response to the mailing list 
post I made came in, which wrote; I remove the personally 
identifiable part and respond:

> I am concerned that I stirred up a hornets nest.

Please don't worry about that -- Bill is sometime so focussed 
on giving answers which are accurate within the four corners 
of the shim, that he may be misunderstood as to easy 
extensions.  Me, too, but with different blind spots.  All of 
us are able to see more than any one of us.  We hoped for (and 
welcome) the challenges running a FOSS project, and 
participating in a mailing list brings.

> From a recent email from Bill, I found that the shim isn't 
> what I need, for it seems that it is unable to store the 
> tick information onto the database.

?? I may have seen a BCC but I don't recall it.  We (Biil and 
I) have to learn to clense and post back into the mailing list 
the previously closed correspondence we have been conducting; 
Bill and I discussed the need for us to do this earlier this 
week at a planning meeting.

The shim is certainly _able_ to do so trivially with a helper 
script.  I know, because I've done it for a couple of years. 
You may have misunderstood Bill's reply, and I will check and 
let you know. I'll send along some scripts on Monday which 
_can_ do it -- but _an_ answer is: you probably don't _want_ 
to do it as the volume of data is so huge.  Indeed, by post 
processing the syslog, or the debug file, all the data is 
there, already.

> I was hoping to be able to get the data stream stored to a 
> sql server and then have my applications access it. However, 
> from Bill's description this isn't how the shim works.

Probably you don't want the raw data stream, but rather the 
results after some post-processing.

But, yes - true with the shim alone within its four corners.

But not true with one additional script.  I'll publish it as 
it is straightforward [but I want to make sur I send a working 
copy, and also it is at my office].  I have not used it for a 
while, as it has been superceded by local efforts on history, 
(and the 5 second recurring history in API 9.2 radically 
changes things further). The analysis behind what we are 
thinking is a little complex (three factors to consider, 
preventing binary partition analysis), and so I'll defer 
giving it here; hang in there with us, please.

>> One devil looks a lot like another ;)  Markup devils are 
>> tricky that way.

> Funny that is what I thought of PCs and windows :)  Though I 
> don't see much of the html or sql code directly. Most is 
> done by a tool that deals with dynamic html code. Only when 
> there is something special, like having the page deal with 
> multiple tables or special checking of a table.

heh -- That was my point. too.  My purpose in the caution was 
to give a 'heads up' to prevent some 'head scratching'.

-- Russ Herrold