According to Geoff Hutchison:
> On Wed, 31 Mar 1999, Gilles Detillieux wrote:
> > I think a better place would be Display::buildMatchList(), because the
> > DocTime() field is in the DocumentRef object, fetched from docDB in this
> > function. No point fetching the record from the database more than once
> > per match.
>
> I'm a bit concerned with the code bloat in Display.cc. I'd like to see
> some of the code moved out of that file to more logical locations. My
> initial assumptions (way back when) were that variable expansion was done
> by the Template object, that sorting and filtering of results were done
> either in htsearch.cc or ResultList, etc.
I agree. I did find it odd that so much of htsearch's logic was in the
Display class, rather than elsewhere, but in the interest of making
additions as unobtrusive as possible, I never chose to reorganise anything.
I was just pointing out to Mike where the existing methods are, but yeah,
when you think about it, why is buildMatchList in Display.cc?
> Of course, Gilles has a good point that it's better to fetch the record
> only once, if possible.
>
> > (2^32-1) is Jan. 19, 2038, 03:14:07 UTC. This field will no doubt become
> > a 64-bit integer before then.
>
> Some systems already have 64-bit dates. As usual, it's best to avoid
> assumptions about the size of types.
Absolutely. That's why I suggested a size independent way of calculating
the maximum value. Please let me know if I got the formula wrong, but I
think it'll work.
> > for the end. This latter value will be the maximum signed value for a
> > time_t, regardless of how many bytes it's eventually defined to be.
>
> True. Then again, shouldn't we be worried about documents published in the
> future?
Uhm, yeah. That's why the default end time for the allowed time range
should be the maximum possible time_t. That way, if you don't specify the
end year, month or day, there is effectively no upper limit to the date of
documents included in the search results. The assumption is that time_t
will always be large enough to accomodate dates the system will need
to deal with. Right now, most (but not all) OSes have a 32-bit time_t.
This will need to change before the late 2030s. A 64-bit time_t will last
over a billion centuries, which should be adequate for our purposes. ;)
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED] containing the single word "unsubscribe" in
the SUBJECT of the message.
