Greetings Gilles, That is a very good suggestion. I suppose it comes down to the question of how many people actually use per-server blocks. If they are rare enough, then I vote we optimise for the common case. The cost of having per-attribute flags is (a) an extra two bits per attribute (which probably becomes 32 bits after alignment issues), and (b) an extra attribute-lookup each time the attribute may be used. (c) extra code to write/debug/document/maintain.
If, say, under 1% of users use per-host attributes, then we could use a single flag. If it is more than 1%, we could "do the right thing" as Giles suggests. As Robert Ribnitz recently pointed out, many people will only index documentation on their own box (that is what brought me to ht://Dig). Of the rest, most probably only index a single site. Of the rest, most probably don't know about the per-host option, because it's documentation isn't very prominent. Thoughts? Lachlan On Thu, 15 Apr 2004 04:52, Gilles Detillieux wrote: > According to Lachlan Andrew: > > If Chris finds that that is in fact the problem, I suggest that: > > 1. We set a flag if per-host attributes are used at all > > 2. If no per-host attributes are used, all expensive-to-parse > > attributes (like regular expressions) should be cached in > > their parsed forms. > > Remember that there are URL blocks as well as server blocks and > globals, so we actually have 3 different levels. It might be > useful to maintain a status for each attribute that tells us the > lowest level at which the attribute is defined. That way even if > some attributes are used in URL blocks, we don't need to reparse > the ones that aren't. -- [EMAIL PROTECTED] ht://Dig developer DownUnder (http://www.htdig.org) ------------------------------------------------------- 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 _______________________________________________ ht://Dig Developer mailing list: [EMAIL PROTECTED] List information (subscribe/unsubscribe, etc.) https://lists.sourceforge.net/lists/listinfo/htdig-dev
