htdig-dev — Developer Discussion for the ht://Dig project

Re: [htdig-dev] head_before_get attribute (was: 3.2RC1 Feature Freeze)

[Gabriele B. <bar...@in...>]

At 13.48 22/10/2003 -0600, Neal Richter wrote:
>   Gabriele:  Please create a sourceforge bug for this when you change
>it... and clue us all in on what the 'net change' is after the commits
>;-).

Sorry ... I forgot to open the bug before. Done everything.

Ciao
-Gabriele
--
Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check 
maintainer
Current Location: Melbourne, Victoria, Australia
bar...@in... | http://www.prato.linux.it/~gbartolini | ICQ#129221447
 > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, The 
Inferno

Re: [htdig-dev] htsearch 3.2 rejects records with modtime of 0?

[Gilles D. <gr...@sc...>]

According to me:
> According to Lachlan Andrew:
> > I've applied a better patch.  The default for  startyear  is empty, 
> > and it is documented that *if* a start/end date is specified then it 
> > defaults to 1970.
> > 
> > Gilles, could you please verify that this fixes the bug, and close the 
> > report?
...
> Yes, I think keeping all of these empty by default is the best approach,
> and the one most like 3.1.6 uses.  I think 3.1.6 with patches has a solid
> implementation of this, so I'll compare the 2 Display codes to see what
> discrepancies I find, and try to figure if these are warranted or not.
> I see no reason to go with option 2 or 3 above.
> 
> However, I haven't seen your patch, nor has it come through in the CVS
> yet if you committed it.  The current htcommon/defaults.cc still has a
> default of 1970.  Can I see the fix for this so I can give it a try?
> It's not attached to the bug report you filed.

Never mind about seeing your fix.  There are some wierd SourceForge delays,
such that some messages arrive quickly while others take a day or more.
I guess there were similar delays with CVS, but your change did come through
yesterday.  I thought you were going to change Display.cc, but I see it was
just defaults.cc that needed fixing.

Anyway, I've got my changes into Display.cc as well, and it all seems to be
working just as it should.  I've closed your bug report.  Could someone do
likewise for bugs 578570 and 829746, as I've applied the bug fixes for
these?

-- 
Gilles R. Detillieux              E-mail: <gr...@sc...>
Spinal Cord Research Centre       WWW:    http://www.scrc.umanitoba.ca/
Dept. Physiology, U. of Manitoba  Winnipeg, MB  R3E 3J7  (Canada)

Re: [htdig-dev] head_before_get attribute (was: 3.2RC1 Feature Freeze)

[Gilles D. <gr...@sc...>]

According to Gabriele Bartolini:
> At 13.45 22/10/2003 -0600, Neal Richter wrote:
> >   OK, you've convinced me, it IS useful to have this switch be user
> >controlled..  I wasn't aware of the non-compliant servers causing an
> >issue.  Clearly 'automatic' behavior in that case is a bad thing.
> >Go with option 2.
> 
> Roger that. :-)

I guess the only safe way to automate the selection of this would be
for htdig to keep track, on a server by server basis, to see if a server
responds favourably to HEAD requests.  If it doesn't, then it would turn
off this action for this server, but otherwise it seems it would almost
always be an advantage to keep it on.  But now we're getting into the
area of feature requests, not bug fixes, so this should wait till after
the upcoming release.

If I'm not mistaken, as the code now stands, htdig will assume a document
is inaccessible if the HEAD request fails, and so it won't try the GET on
that document at all (unless head_before_get is explicitly set to false).
So, properly automating this selection would require some code changes
to the HtHTTP classs to implement this -- not something we want to start
monkeying with at the eleventh hour before release.

I think the current compromise is best, but it should be given a good
pounding to make sure it's solid.

-- 
Gilles R. Detillieux              E-mail: <gr...@sc...>
Spinal Cord Research Centre       WWW:    http://www.scrc.umanitoba.ca/
Dept. Physiology, U. of Manitoba  Winnipeg, MB  R3E 3J7  (Canada)

[htdig-dev] [Task #87784] Parsing

[SourceForge.net <no...@so...>]

Task #87784 has been updated. 

Project: ht://Dig
Subproject: Testing 3.2
Summary: Parsing
Complete: 0%
Status: Open
Authority  : nealr
Assigned to: nobody

Description: Use the documenation to test each one of these config verbs

#parsing

description_meta_tag_names

date_format

ignore_alt_text

max_doc_size

max_keywords

max_meta_description_length

max_description_length

max_descriptions

max_excerpts

max_head_length

noindex_end

noindex_start

mime_types

content_classifier

external_parsers

external_protocols

use_meta_description



-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=87784&group_id=4593&group_project_id=32485

[htdig-dev] Re: defaults.cc and 'head_before_get'

[Lachlan A. <lh...@us...>]

Greetings all,

I've found the problem:  In  setVariables(),  the command=20
vars.Add("PAGEHEADER", new String(config->Find("page_list_header")));
is executed before the command
vars.Add("PAGELIST", str);
That means that ${PAGELIST} is expanded as empty when the string is=20
created.

Swapping the order of these solves the particular problem, but the=20
more fundamental problem is that any variable can (or should be able=20
to be) defined in terms of any other, and there is no ordering which=20
can allow that.  One possibility would be to go through and set each=20
variable *twice*, so that second time around, most variables should=20
have their right values.  Of course, chains of variables defined in=20
terms of each other would need more than two iterations...

Another option would be to merge  vars  with  config  so that the=20
literal string  ${PAGELIST}  would be added, and only evaluated when=20
the variable is finally expanded during output.

Cheers,
Lachlan


On Fri, 24 Oct 2003 22:49, Lachlan Andrew wrote:
> Are variables in (no_)page_list_header supposed to be expanded?
>
> If  page_list_header =3D ${PAGELIST} then PAGEHEADER is empty when
> there is more than one page, even though  PAGELIST  isn't.
--=20
lh...@us...
ht://Dig developer DownUnder  (http://www.htdig.org)

[htdig-dev] [Task #87776] Valid Words

[SourceForge.net <no...@so...>]

Task #87776 has been updated. 

Project: ht://Dig
Subproject: Testing 3.2
Summary: Valid Words
Complete: 95%
Status: Open
Authority  : nealr
Assigned to: lha

Description: Use the documenation to test each one of these config verbs



# valid words

allow_numbers

extra_word_characters(1)

valid_punctuation

locale(1)

minimum_word_length

bad_word_list

maximum_word_length

translate_latin1(1)

Follow-Ups:

-------------------------------------------------------
Date: 2003-10-24 21:10
By: lha

Comment:
Could someone else please check  locale  and then close this task?  Thanks!

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=87776&group_id=4593&group_project_id=32485

[htdig-dev] Re: defaults.cc and 'head_before_get'

[Gabriele B. <bar...@in...>]

At 23.01 24/10/2003 +1000, Lachlan Andrew wrote:
>On Thu, 23 Oct 2003 21:51, Gabriele Bartolini wrote:
>
> >     can you please revise the defaults.cc documentation for the
> > 'head_before_get' attribute. I wrote something but it needs some
> > revision by english mother-tongue developers.
>
>Your English is fine.  I've made a few changes below, if you're
>interested (but it was OK as it was).

Thanks Lachlan. :-)

I will change the defaults.cc file asap. I am not on Linux now, I will do 
it when I come back or tomorrow morning.

-Gabriele
--
Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check 
maintainer
Current Location: Melbourne, Victoria, Australia
bar...@in... | http://www.prato.linux.it/~gbartolini | ICQ#129221447
 > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, The 
Inferno

[htdig-dev] Re: Testing Tasks

[Lachlan A. <lh...@us...>]

Greetings all,

Thanks, Neal, for your work setting up the tasks!

When I run  valgrind,  I get
=3D=3D4058=3D=3D Conditional jump or move depends on uninitialised value(=
s)
=3D=3D4058=3D=3D    at 0x40300421: CDB___lock_put_nolock (lock.c:650)
from various contexts.

I don't fancy changing the BDB code (my last foray was rather=20
forgettable :)  Does anyone think that this is an issue, or should we=20
ignore it?

Cheers,
Lachlan

On Fri, 24 Oct 2003 01:09, Neal Richter wrote:

> I would also encourage each of you to use valgrind to check for
> memory leaks while you are testing. Again, the depth you go looking
> for them is up to you.

--=20
lh...@us...
ht://Dig developer DownUnder  (http://www.htdig.org)

[htdig-dev] [Task #87781] htdig Spidering

[SourceForge.net <no...@so...>]

Task #87781 has been updated. 

Project: ht://Dig
Subproject: Testing 3.2
Summary: htdig Spidering
Complete: 0%
Status: Open
Authority  : nealr
Assigned to: nobody

Description: Use the documenation to test each one of these config verbs

# spidering

max_hop_count

start_url

robotstxt_name(1)

check_unique_date(1)

check_unique_md5

md5_db

limit_normalized

limit_urls_to

exclude_urls

bad_querystr

url_rewrite_rules

url_part_aliases

local_urls

local_urls_only

local_user_urls

valid_extensions

bad_extensions

bad_local_extensions



-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=87781&group_id=4593&group_project_id=32485

Re: [htdig-dev] head_before_get attribute (was: 3.2RC1 Feature Freeze)

[Gabriele B. <bar...@in...>]

At 10.19 23/10/2003 -0500, Gilles Detillieux wrote:
>I guess the only safe way to automate the selection of this would be
>for htdig to keep track, on a server by server basis, to see if a server
>responds favourably to HEAD requests.  If it doesn't, then it would turn
>off this action for this server, but otherwise it seems it would almost
>always be an advantage to keep it on.  But now we're getting into the

That's what actually happens with persistent connections. However, for 
instance, the 'Limit' directive with apache can be set by directories or 
locations and I would not risk to disable the attribute for every document 
on the server just because one failed. Again, I guess that the 'webmaster' 
is the one that knows his scenario better than any one.

>If I'm not mistaken, as the code now stands, htdig will assume a document
>is inaccessible if the HEAD request fails, and so it won't try the GET on
>that document at all (unless head_before_get is explicitly set to false).

Hmmm ... by looking at the code in HtHTTP::Request(), we should add an 'if 
statement' for the case when the server returns a 405 status code. We 
should also add a proper Document Status for this in the Transport class 
(Document_method_not_allowed?).

Basically when we issue a HEAD method and we get a not allowed method 
response, we should get the resource.

What do you think? Anyway, I am going to open a feature request for this so 
we keep it in mind.

>So, properly automating this selection would require some code changes
>to the HtHTTP classs to implement this -- not something we want to start
>monkeying with at the eleventh hour before release.

I agree.

Ciao,
-Gabriele
--
Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check 
maintainer
Current Location: Melbourne, Victoria, Australia
bar...@in... | http://www.prato.linux.it/~gbartolini | ICQ#129221447
 > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, The 
Inferno

[htdig-dev] [Task #87771] htfuzzy

[SourceForge.net <no...@so...>]

Task #87771 has been updated. 

Project: ht://Dig
Subproject: Testing 3.2
Summary: htfuzzy
Complete: 100%
Status: Closed
Authority  : nealr
Assigned to: lha

Description: Use documentation and test each of these config verbs:



# fuzzy	

accents_db(1)			

endings_root2word_db		

endings_word2root_db		

metaphone_db			

soundex_db			

synonym_db			

endings_affix_file		

endings_dictionary		

synonym_dictionary		

prefix_match_character		

search_algorithm		



# fuzzy limitations

minimum_speling_length

substring_max_words

max_prefix_matches		

minimum_prefix_length		

regex_max_words





-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=87771&group_id=4593&group_project_id=32485

[htdig-dev] Re: SSL troubles

[Lachlan A. <lh...@us...>]

Greetings Andy,

Thanks for submitting the bug report.  Having seen how much testing=20
there is to go, I think it might be best to delay fixing this until=20
after 3.2.0 is released.  I hope that 3.2.1 won't be far behind, and=20
in the mean time, we can put the patch on a website somewhere.  It's=20
just that the current configuration procedure took a long time to=20
make portable, and I don't want to break it at this stage.  Is that=20
OK?

Cheers,
Lachlan

On Fri, 24 Oct 2003 03:59, And...@wi... wrote:

> I submitted a bug fix. I'll try to test those patches tonight.

>  "I'm not sure what LInux-friendly means"
> Martin Taylor, MicroSoft's Linux strategist

*grin*

--=20
lh...@us...
ht://Dig developer DownUnder  (http://www.htdig.org)

[htdig-dev] [Task #87778] Template Variables

[SourceForge.net <no...@so...>]

Task #87778 has been updated. 

Project: ht://Dig
Subproject: Testing 3.2
Summary: Template Variables
Complete: 5%
Status: Open
Authority  : nealr
Assigned to: lha

Description: Use the documenation to test each one of these config verbs



# template variables

end_ellipses

start_ellipses

end_highlight

start_highlight

star_blank

star_image

star_patterns

image_url_prefix

plural_suffix

script_name

boolean_keywords(1)

boolean_syntax_errors(1)

page_number_separator

page_number_text

no_title_text



-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=87778&group_id=4593&group_project_id=32485

[htdig-dev] [Task #87778] Template Variables

[SourceForge.net <no...@so...>]

Task #87778 has been updated. 

Project: ht://Dig
Subproject: Testing 3.2
Summary: Template Variables
Complete: 0%
Status: Open
Authority  : nealr
Assigned to: nobody

Description: Use the documenation to test each one of these config verbs



# template variables

end_ellipses

start_ellipses

end_highlight

start_highlight

star_blank

star_image

star_patterns

image_url_prefix

plural_suffix

script_name

boolean_keywords(1)

boolean_syntax_errors(1)

page_number_separator

page_number_text

no_title_text



-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=87778&group_id=4593&group_project_id=32485

[htdig-dev] Re: expanding variables in page_list_header

[Lachlan A. <lh...@us...>]

Greetings Gilles,

Yes, I realised after I had shut down yesterday that what I was seeing=20
was not faulty recursive expansion of a template variable, but just=20
the natural behaviour of configuration variables being expanded.

The reason I thought it was sensible for the PAGEHEADER to have the=20
page list is that I assumed it was the page header(!), rather than a=20
separator for the page list.  I was wondering why the page would have=20
a different header depending on the number of pages, except for the=20
possibility of showing the page list.

Thanks for your patience in clearing that up :)

Lachlan

On Sat, 25 Oct 2003 04:53, Gilles Detillieux wrote:
> What you're suggesting,
> though, would be for attribute definitions to be able to refer to
> template variable values, or for template variable expansion to be
> applied recursively. Either way, it's a new feature

> this doesn't seem at
> all sensible considering how these template variables are currently
> set and used.  The standard footer.html begins with...
>
> $(PAGEHEADER)
> $(PREVPAGE) $(PAGELIST) $(NEXTPAGE)

--=20
lh...@us...
ht://Dig developer DownUnder  (http://www.htdig.org)

Re: [htdig-dev] expanding variables in page_list_header

[Gilles D. <gr...@sc...>]

According to Lachlan Andrew:
> Are variables in (no_)page_list_header supposed to be expanded?

In the general case, attribute definitions can refer to other attribute
definitions to get their values.  What you're suggesting, though, would
be for attribute definitions to be able to refer to template variable
values, or for template variable expansion to be applied recursively.
Either way, it's a new feature, not trivial to implement (I'd guess) and
with the potential to introduce new bugs/complications.  Not something
I'd suggest doing just prior to release.

> If  page_list_header = ${PAGELIST}  (which seems a sensible value) 

I'm not sure what you're getting at, because this doesn't seem at all
sensible considering how these template variables are currently set
and used.  The standard footer.html begins with...

$(PAGEHEADER)
$(PREVPAGE) $(PAGELIST) $(NEXTPAGE)

where PAGEHEADER is set to no_page_list_header if there is only one
page of results, or page_list_header otherwise.  PAGELIST is the list
of buttons and/or text links to other result pages.  Why would you want
to set PAGEHEADER to the value of PAGELIST?

> then PAGEHEADER is empty when there is more than one page, even 
> though  PAGELIST  isn't.  Before I submit a bug report, is the 
> correct behaviour for it to expand to the value of PAGELIST, or to 
> remain the literal string "${PAGELIST}"?

As far as I can tell, the code is correct and stable right now.  Maybe
I'm misunderstanding what you're trying to accomplish, and how you're
attempting to go about it.  Do you think attribute definitions ought to
be able to reference template variables (probably extremely tricky to
implement) or that template variables should be expanded recursively?
What do your config file and template look like?

-- 
Gilles R. Detillieux              E-mail: <gr...@sc...>
Spinal Cord Research Centre       WWW:    http://www.scrc.umanitoba.ca/
Dept. Physiology, U. of Manitoba  Winnipeg, MB  R3E 3J7  (Canada)

Re: [htdig-dev] htsearch 3.2 rejects records with modtime of 0?

[Gilles D. <gr...@sc...>]

According to Lachlan Andrew:
> Greetings,
> 
> I've applied a better patch.  The default for  startyear  is empty, 
> and it is documented that *if* a start/end date is specified then it 
> defaults to 1970.
> 
> Gilles, could you please verify that this fixes the bug, and close the 
> report?
...
> On Thu, 23 Oct 2003 00:05, Lachlan Andrew wrote:
> > The three fixes I can think of are:
> >
> > 1. Set the (hard-coded) default value of  startday  in
> >    htsearch/Display.cc to 0 instead of 1. I'm not sure if this
> >    would work, and it may break other things.
> > 2. Leave  startyear  empty in defaults.cc and manually hack
> >    attrs.hml.
> > 3. Leave  startyear  undocumented.

Yes, I think keeping all of these empty by default is the best approach,
and the one most like 3.1.6 uses.  I think 3.1.6 with patches has a solid
implementation of this, so I'll compare the 2 Display codes to see what
discrepancies I find, and try to figure if these are warranted or not.
I see no reason to go with option 2 or 3 above.

However, I haven't seen your patch, nor has it come through in the CVS
yet if you committed it.  The current htcommon/defaults.cc still has a
default of 1970.  Can I see the fix for this so I can give it a try?
It's not attached to the bug report you filed.

Thanks.

-- 
Gilles R. Detillieux              E-mail: <gr...@sc...>
Spinal Cord Research Centre       WWW:    http://www.scrc.umanitoba.ca/
Dept. Physiology, U. of Manitoba  Winnipeg, MB  R3E 3J7  (Canada)

[htdig-dev] Re: defaults.cc and 'head_before_get'

[Lachlan A. <lh...@us...>]

On Thu, 23 Oct 2003 21:51, Gabriele Bartolini wrote:

>     can you please revise the defaults.cc documentation for the
> 'head_before_get' attribute. I wrote something but it needs some
> revision by english mother-tongue developers.

Your English is fine.  I've made a few changes below, if you're=20
interested (but it was OK as it was).

Cheers,
Lachlan

If set to true, an HTTP/1.1 <em>HEAD</em>
call is made in order to retrieve header information about a document.
If the status code and the content-type returned show that the=20
document is parsable, then a subsequent 'GET' call is made.  In=20
general, it is recommended that this attribute be set to 'true',
as it can really improve performance (especially when used with=20
persistent connections).  This is particularly so during an=20
incremental dig, since in this case 'htdig' can ask the server if the=20
document has been modified since last dig. However there are a few=20
cases when it is better to switch it off:
<ul>
<li>the majority of documents are parsable (HTML or a type for which=20
an external parser has been provided) and must be retrieved anyway=20
(initial dig);</li>=20
<li>the server does not support the HEAD method or it is=20
disabled;</li>=20
<li>in some cases persistent connections
(<a href=3D\"#persistent_connections\">persistent_connections</a>) may=20
not work properly and either the 'head_before_get' attribute or the=20
'persistent_connections' attribute must be turned off.
</li>
</ul>

--=20
lh...@us...
ht://Dig developer DownUnder  (http://www.htdig.org)

[htdig-dev] expanding variables in page_list_header

[Lachlan A. <lh...@us...>]

Greetings all,

Are variables in (no_)page_list_header supposed to be expanded?

If  page_list_header =3D ${PAGELIST}  (which seems a sensible value)=20
then PAGEHEADER is empty when there is more than one page, even=20
though  PAGELIST  isn't.  Before I submit a bug report, is the=20
correct behaviour for it to expand to the value of PAGELIST, or to=20
remain the literal string "${PAGELIST}"?

Thanks,
Lachlan
--=20
lh...@us...
ht://Dig developer DownUnder  (http://www.htdig.org)

[htdig-dev] [Task #87782] WWW protocol related

[SourceForge.net <no...@so...>]

Task #87782 has been updated. 

Project: ht://Dig
Subproject: Testing 3.2
Summary: WWW protocol related
Complete: 0%
Status: Open
Authority  : nealr
Assigned to: nobody

Description: Use the documenation to test each one of these config verbs

# protocol

accept_language(1)

disable_cookies

cookies_input_file

head_before_get

http_proxy

http_proxy_authorization

http_proxy_exclude

ignore_dead_servers

max_retries

persistent_connections

robotstxt_name(2)

server_max_docs

server_wait_time

tcp_max_retries

tcp_wait_time

timeout

user_agent

authorization

max_connection_requests

nph





-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=87782&group_id=4593&group_project_id=32485

[htdig-dev] Re: htsearch 3.2 rejects records with modtime of 0?

[Lachlan A. <lh...@us...>]

Greetings,

I've applied a better patch.  The default for  startyear  is empty,=20
and it is documented that *if* a start/end date is specified then it=20
defaults to 1970.

Gilles, could you please verify that this fixes the bug, and close the=20
report?

Thanks,
Lachlan

On Thu, 23 Oct 2003 00:05, Lachlan Andrew wrote:
> The three fixes I can think of are:
>
> 1. Set the (hard-coded) default value of  startday  in
>    htsearch/Display.cc to 0 instead of 1. I'm not sure if this
>    would work, and it may break other things.
> 2. Leave  startyear  empty in defaults.cc and manually hack
>    attrs.hml.
> 3. Leave  startyear  undocumented.

--=20
lh...@us...
ht://Dig developer DownUnder  (http://www.htdig.org)

[htdig-dev] [Task #87791] Miscellaneous

[SourceForge.net <no...@so...>]

Task #87791 has been updated. 

Project: ht://Dig
Subproject: Testing 3.2
Summary: Miscellaneous  
Complete: 0%
Status: Open
Authority  : nealr
Assigned to: nobody

Description: Use the documenation to test each one of these config verbs



collection_names

excerpt_length

keywords_meta_tag_names

match_method

template_map

template_name

template_patterns

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=87791&group_id=4593&group_project_id=32485

[htdig-dev] [Task #87779] URL - filters etc DELETED

[SourceForge.net <no...@so...>]

Task #87779 has been updated. 

Project: ht://Dig
Subproject: Testing 3.2
Summary: URL - filters etc DELETED
Complete: 100%
Status: Open
Authority  : nealr
Assigned to: nobody

Description: Use the documenation to test each one of these config verbs

# URLs

allow_double_slash

allow_virtual_hosts

case_sensitive

bad_extensions

limit_normalized

limit_urls_to

local_default_doc

remove_default_doc

common_url_parts

exclude_urls

valid_extensions

url_log

url_part_aliases

url_rewrite_rules

url_seed_score

server_aliases

restrict

exclude

bad_local_extensions

local_urls

local_urls_only

local_user_urls





-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=87779&group_id=4593&group_project_id=32485

[htdig-dev] [Task #87771] htfuzzy

[SourceForge.net <no...@so...>]

Task #87771 has been updated. 

Project: ht://Dig
Subproject: Testing 3.2
Summary: htfuzzy
Complete: 0%
Status: Open
Authority  : nealr
Assigned to: lha

Description: Use documentation and test each of these config verbs:



# fuzzy	

accents_db(1)			

endings_root2word_db		

endings_word2root_db		

metaphone_db			

soundex_db			

synonym_db			

endings_affix_file		

endings_dictionary		

synonym_dictionary		

prefix_match_character		

search_algorithm		



# fuzzy limitations

minimum_speling_length

substring_max_words

max_prefix_matches		

minimum_prefix_length		

regex_max_words





-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=87771&group_id=4593&group_project_id=32485

[htdig-dev] defaults.cc and 'head_before_get'

[Gabriele B. <bar...@in...>]

Guys,

    can you please revise the defaults.cc documentation for the 
'head_before_get' attribute. I wrote something but it needs some revision 
by english mother-tongue developers.

    Also, I didn't generate the documentation by purpose. Please let's 
remember to do it before we go in release.

Ciao,
-Gabriele
--
Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check 
maintainer
Current Location: Melbourne, Victoria, Australia
bar...@in... | http://www.prato.linux.it/~gbartolini | ICQ#129221447
 > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, The 
Inferno