Re: [htdig-dev] Re: [htdig] Using cookies

[Gabriele Bartolini <angusgb@ti...>]

Ciao Gilles,

    thanks for pointing to the cookies patch. Yes, it is a backporting 
patch from 3.2.x and works pretty well on my Linux system. I expect other 
people on different platforms to test it and give me some feedback 
regarding portability.

    As far as patch posting is concerned, I don't know whether Joe received 
my e-mail 2 days ago. If you need more stuff please tell me, ok?

>How you'd use that for authorisation may be another matter, though.
>I don't know if Gabriele's cookie support has a way of pre-loading cookies
>from another browser into htdig's cookie jar.  Care to comment, Gabriele?
>(Or anyone else for that matter?)

    Well, to be sincere it is not a difficult thing. The code was designed 
to support any kind of Cookies storage, it is pretty flexible indeed. For 
now only the memory jar is supported. This regards though the persistency 
of cookies among different crawls, which is different to the pre-loading of 
cookies. This should not be a big work to do as I just said.

    We only need a format for storing them. We could decide this, if you 
want. My vote would be to store them in a text file using the HTTP syntax. 
By doing this, we would avoid any kind of parsing and the insertion into 
the memory Jar would be straightforward.

     I don't know though if this is a flexible solution and the right one, 
because it seems to go against the usual way of configuration and leads in 
some cases to confusion (a user should use the specific and exact syntax in 
order to issue one or more cookies). Any ideas?

Ciao ciao and thanks for rising up the topic
-Gabriele
--
Gabriele Bartolini - Web Programmer
Current Location: Prato, Tuscany, Italia
angusgb@... | http://www.prato.linux.it/~gbartolini | ICQ#129221447
 > find bin/laden -name osama -exec rm {} \;

Re: [htdig-dev] Re: [htdig] Using cookies

[Joe R. Jah <jjah@cl...>]

On Fri, 6 Sep 2002, Gilles Detillieux wrote:

> Date: Fri, 6 Sep 2002 13:50:49 -0500 (CDT)
> From: Gilles Detillieux <grdetil@...>
> To: adam@...
> Cc: htdig-general@..., htdig-dev@...
> Subject: [htdig-dev] Re: [htdig] Using cookies
> 
> According to Adam Brown:
> > The site I am indexing uses cookies for authorisation. I am guessing I will 
> > need to write a wrapper to htdig to log in to the site with the appropriate 
> > user name and password and then store the cookie data in Htdig somewhere so 
> > that it is authorised to browse the site. 
> > 
> > How do I do this or could someone please point me to the appropriate 
> > documentation.
> 
> I don't know if you noticed, but Gabriele posted a patch to 3.1.6
> yesterday that adds cookie support.  It hasn't made it onto the patch
> archives yet, but no doubt it will soon (right, Joe?), so you can look
> for it there if you can't find it on the htdig-dev mailing list archives.
> It seems to be a backport of the cookie support in 3.2.0b4.  So, whether
> you use a recent snapshot of 3.2.0b4, or use 3.1.6 with Gabriele's patch,
> you should be able to get cookie support going with htdig.
> 
> How you'd use that for authorisation may be another matter, though.
> I don't know if Gabriele's cookie support has a way of pre-loading cookies
> from another browser into htdig's cookie jar.  Care to comment, Gabriele?
> (Or anyone else for that matter?)

Thank you Gilles for the reminder.  I saved it yesterday to cookies.gz.0
file, but then I got caught up with a flood of work, and forgot to move it
to the patch site;(  It's now in:

	ftp://ftp.ccsf.org/htdig-patches/3.1.6/cookies.gz.0

Regards,

Joe
-- 
     _/   _/_/_/       _/              ____________    __o
     _/   _/   _/      _/         ______________     _-\<,_
 _/  _/   _/_/_/   _/  _/                     ......(_)/ (_)
  _/_/ oe _/   _/.  _/_/ ah        jjah@...

[htdig-dev] Re: [htdig] Using cookies

[Gilles Detillieux <grdetil@sc...>]

According to Adam Brown:
> The site I am indexing uses cookies for authorisation. I am guessing I will 
> need to write a wrapper to htdig to log in to the site with the appropriate 
> user name and password and then store the cookie data in Htdig somewhere so 
> that it is authorised to browse the site. 
> 
> How do I do this or could someone please point me to the appropriate 
> documentation.

I don't know if you noticed, but Gabriele posted a patch to 3.1.6
yesterday that adds cookie support.  It hasn't made it onto the patch
archives yet, but no doubt it will soon (right, Joe?), so you can look
for it there if you can't find it on the htdig-dev mailing list archives.
It seems to be a backport of the cookie support in 3.2.0b4.  So, whether
you use a recent snapshot of 3.2.0b4, or use 3.1.6 with Gabriele's patch,
you should be able to get cookie support going with htdig.

How you'd use that for authorisation may be another matter, though.
I don't know if Gabriele's cookie support has a way of pre-loading cookies
from another browser into htdig's cookie jar.  Care to comment, Gabriele?
(Or anyone else for that matter?)

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

Re: [htdig-dev] OS X 10.2

[Gilles Detillieux <grdetil@sc...>]

According to Jim Cole:
> Gilles Detillieux's bits of Thu, 5 Sep 2002 translated to:
> >Yes, this was reported just a few weeks ago, and a patch was provided.
> >See ftp://ftp.ccsf.org/htdig-patches/3.1.6/
> 
> Sorry. I somehow missed that post. However, even with the patch I
> believe the code in both 3.1.6 and 3.2.x is incorrect. If the
> name of a non-existent file was provided, the same problem with
> infinite looping could occur. As I understand the standard, the
> check of in.bad() is of no use with regard to whether the file
> was opened successfully. If on the other hand in.good() is
> checked, then it would ensure that neither badbit nor failbit is
> set.

This is what I really hate about C++!  So many of the so-called standard
classes aren't really that standard, and vary from one implementation to
another, and one release to another.  How intuitive is this?  bad() is
not to be taken as an antonym of good()?  If what you're saying is true,
then 3.1.x's htlib/Configuration.cc code will also bomb if it can't open
the config file.  So, just how standard is the behaviour you describe?
If we start using in.good() in htnotify.cc and Configuration.cc, instead
of !in.bad(), will the code work correctly on all supported platforms,
or will it start to bomb on some of the systems where !in.bad() used to
work fine?  Do we need configure tests for all this nonsense?

On the g++ implementations I have on two different Red Hat Linux systems,
good() seems to represent the absence of eofbit, badbit and failbit,
but I can't find any information on what the distinction is between
badbit and failbit.  Is this consistent across all platforms?  If so,
why haven't we had a flurry of bug reports about htdig 3.1.x bombing
when the config file can't be opened?

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

Re: [htdig-dev] cannot search sites other than port 80

[Gilles Detillieux <grdetil@sc...>]

According to Stephan Hartmann:
> Hi developers,
> 
> when i give a start_url with port 8080 (tomcat) and the webapp's servlet 
> sends a redirect, htdig does not get any further. The reason seems to be that 
> htdig does not include the port in the Host header of the first HTTP-Request.
> Example:
> 
> the start_url is http://localhost:8080/mywebapp/myservlet/
> 
> htdig sends this request:
> 
> GET /robots.txt HTTP/1.0
> User-Agent: htdig/3.1.5 (myemail)
> Host: localhost
> 
> i think, Host should be localhost:8080 instead. At least mozilla does this.
> 
> Now if the servlet sends a redirect, it does send it without the port what 
> leads to a wrong redirect.
> 
> Can anybody confirm this behavior?

Yes.  It's fixed in 3.1.6:

Fri Sep 14 09:18:38 2001  Gilles Detillieux  <grdetil@...>

        * htdig/Document.cc (RetrieveHTTP): Add port to Host: header when
        port is not default, as per RFC2616(14.23). Fixes bug #459969.

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

Re: [htdig-dev] Adjustable logging patch.

[Gilles Detillieux <grdetil@sc...>]

According to Brian White:
> At 09:10 6/09/2002, Gilles Detillieux wrote:
> >Well, while going with POSIX-compliant locking would help with
> >portability, I'm not sure all systems currently supported by 3.1.x
> >are fully POSIX-compliant either, so it may be that some only support
> >flock(), or even perhaps no locking at all.  Some configure tests for
> >various locking schemes should be implemented, so the code uses what
> >the system provides, or no locking at all if nothing appropriate is found.
> 
> I already have "locked" and "unlocked" versions of the code, managed by
> an #ifdef - I would just have to add a  -D__NO_FILE_LOCKING__ or something
> like that.

Yes.  Ideally, though, it would be automated via configure tests.
For example, you test for the flock() call and define HAVE_FLOCK
in htconfig.h.  Then the code uses #ifdef HAVE_FLOCK.  Similarly,
you define something like HAVE_FCNTL_LOCK if that capability exists.
That test is a bit more complex, as it's not just testing for the
existance of a library function.

> I assume this means I would need to create a patch for the configure
> script - any tips on how to do that? Is that monster *really* maintained
> solely by hand or is there some tools for it?

It's generated from configure.in by the autoconf program.  So,
configure.in is the monster we maintain by hand, which isn't quite as
big and scary as the configure script itself.  Still, you need to learn
enough about autoconf to get by, which is more than I know at this point.

> > > 3) It should be simple enough to create a patch that works with 3.2.x,
> > >     judging by a quick look at the latest Display.cc in the CVS repository.
> > >
> > > I *would* like to get it rolled into 3.1.x if I can. I am
> > > more than willing to make any changes required to make this
> > > happen.
> >
> >I think it would be good to see this in the 3.2 CVS tree, with the
> >appropriate configure tests.  I'm still a bit lukewarm on the addition
> >of the "init" input parameter to htsearch.  It seems the absense of a
> >"page" parameter would mean the same thing, wouldn't it?
> 
> You know, I hadn't even thought of that. The only disadvantage to it
> is that it isn't explicit - I can see someone setting "Page=1" for their
> initial search and wondering why their logging doesn't work. The only
> way around this would be documentation, with notes
> 
>     1) Where the "page" parameter is discuseed
>     2) Where the logging attributes are discussed
>     3) In the FAQs
> 
> Otherwise - Yes! Perfect!

Not to mention writing attrs.html entries (and links in cf_by????.html) for
all the new attributes.  This is of course easier in 3.2.

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

[htdig-dev] cannot search sites other than port 80

[Stephan Hartmann <beffe@be...>]

Hi developers,

when i give a start_url with port 8080 (tomcat) and the webapp's servlet 
sends a redirect, htdig does not get any further. The reason seems to be that 
htdig does not include the port in the Host header of the first HTTP-Request.
Example:

the start_url is http://localhost:8080/mywebapp/myservlet/

htdig sends this request:

GET /robots.txt HTTP/1.0
User-Agent: htdig/3.1.5 (myemail)
Host: localhost

i think, Host should be localhost:8080 instead. At least mozilla does this.

Now if the servlet sends a redirect, it does send it without the port what 
leads to a wrong redirect.

Can anybody confirm this behavior?

Bye,
Stephan 

Re: [htdig-dev] changes for 3.1.7 (was: Adjustable logging patch.)

[Gilles Detillieux <grdetil@sc...>]

According to Joe R. Jah:
> Would you please list the patches you have already committed to CVS, and
> those you may, so that we can carry over the rest as patches to 3.1.7
> folder.

Actually, I haven't begun committing changes to CVS yet.  As for 3.1.6,
I'll probably wait until I have a sufficiently large and complete to-do
list, and a good chunk of time I can devote to the task (which I don't
have now), and then get a flurry of commits happening.

All I have right now is a to-do list of 23 bug fixes, some of which exist
in patches and some of which need to be written still.  I also need to go
through the set of existing patches to see what's ready to use as-is, what
needs tweaking/configure test/documentation, and what I'll exclude.

> Here is the list as of: Thu Sep 5 17:38:47 PDT 2002:
> 
> Patch                        # of downloads
> -----                        --------------
> ssl.9                          193
> timet_enddate.1                182
> Makefile.0                      78
> documentation.1                 68
> metadate.0                      65
> redirect.0                      51
> documentation.2                 50
> NUL.0                           47
> AdjustableLoggingPatch.tar.gz   44
> fileSpace.1                     42
> titleSpace.0                    36
> multiple-noindex.1              34
> Date-viewing.0                  32
> time_t.0                        27
> gcc-3.1.0                       22
> ExecutionTime.0                  9
> ExternalParser-max_doc_size.0    7
> htnotifyNull.0                   6

Offhand, I'd break them down thus...

Include as-is				Leave out
-------------				---------
Date-viewing.0				AdjustableLoggingPatch.tar.gz
ExternalParser-max_doc_size.0		ExecutionTime.0
Makefile.0				multiple-noindex.1
documentation.1				ssl.9
documentation.2				titleSpace.0
gcc-3.1.0
metadate.0
redirect.0
time_t.0
timet_enddate.1

Unsure/needs work
-----------------
fileSpace.1	(new feature, needs docs, but simple/clean/portable & in demand)
NUL.0		(needs config attribute & docs, adds overhead)
htnotifyNull.0	(still has problems with in.bad() handling)

For those who are interested, my current, sketchy to-do list for 3.1.7 is...

 - back out Gabriele's CVS changes of Aug 13
 - fix "not HTML" error message to something like "unknown Content-type".
 + server_wait_time is currently misspelled in cf_byname.html
 + string list description explains quoted string list in cf_types.html
 + htmerge -m is unclear (fixed in maindocs)
 + Marchand's patch to htsearch/Display.cc (fix enddate bug)
 + Marchand's patch to Makefile.config.in (use DEFS)
 + fix parsedcdate() in Retriever.cc to allow '-' after year
 - fix parsedcdate() in Retriever.cc to handle server's local timezone
 + "dc.date.modified" handling patch (May 17)
 - handle -ve scores and/or locations in WordList::Word()
 - fix parsers not to overflow location calc (find e-mail about this)
 - handle location_factor attr. in WordList::Word(), check bounds
 - checks for -ve scores in Display.cc
 - better handling of multimatch_factor, using a new count field in DocMatch
 - keep docdb records for noindex docs, just not words, so updates check these
 - don't delete ANCHOR just because it's not in excerpt
 - better handling of sup & sub tags in HTML.cc, optionally treat as punctuation
 - new catdoc link: http://www.ice.ru/~vitus/catdoc/ in contrib/* parsers
 - less verbose output from htnotify -v, require 2 or more v's for that
 - Martin Vorlaender's VMS patches
 + patch #548448 dealing with unsigned time_t (Apr 25)
 - handle nulls in text/* files (convert to space)

where + means fixed in maindocs or a complete patch, and - means needs
work.  As you can see, my to-do list and the list of patches I want
aren't even mutually complete, though most patches I want are mentioned
in the to-do list.  I've no doubt missed some things on my list that
have been discussed as important/urgent before, but never got around to
noting them.  If anyone wants to help complete the list, or better yet
knock off (i.e. implement) some items on the list, more power to you.

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

Re: [htdig-dev] Questions about htdig-3.2.0b3/htcommon/defaults.cc

[Geoff Hutchison <ghutchis@ws...>]

On Fri, 6 Sep 2002, Brian White wrote:

> I was looking at defaults.cc and I was wondering if
> it might be better managing the info as an XML file
> and then using that as a basis for generating
> defaults.cc and the HTML docs.

Yes, this would actually be quite wonderful. Currently, it's hard to
"validate" changes you make to defaults.cc. It's also a minor pain to
insert and format HTML, since it has to be properly escaped. (No, it's not
a big deal, but XML would obviously be easier.)

> Disadvantages
>    * Part of the build process for exexcutabe would require
>      perl to exist

No, not really. We have lots of "autogenerated" files in 3.2. You'd only
need Perl if you modified defaults.xml and needed to generate the new
defaults.cc.

>    * After rabbiting on like this I now have to decide
>      if I willing to put my money where my mouth is.....

Yes, now that's the question. :-)

Formatting defaults.cc into defaults.xml isn't hard and I'd be glad to do
that with some emacs macros. But I'd be glad to accept this change if you
(or someone) will write the defaults_generate.pl script. Ideally the
script would have some nice error-checking to tell you if you've left out
a field, etc.

--
-Geoff Hutchison
Williams Students Online
http://wso.williams.edu/

Re: [htdig-dev] Adjustable logging patch.

[Geoff Hutchison <ghutchis@ws...>]

On Fri, 6 Sep 2002, Brian White wrote:

> Ok - my desire to get it into 3.1.x is based around the fact that
> we have installed 3.1.6 at a large client site, with the AdjustableLogging
> patch installed. In fact, it was written for their installation.
> It makes long term support slightly easier if the product is *fully* off the
> shelf.

No offense, but there are a variety of packaging mechanisms which will
also add a patch (.rpm, .deb, etc.) for various local modifications. I
also would agree with Gilles that your patch seems like a rather large
feature to be adding when we really want to "finish" 3.1.x releases.

> However, that said - getting it into the 3.2 CVS tree means by the
> time it ever becomes a genuine issue, a stable 3.2 release should
> be available for use. I would be happy with that.

OK, then let's talk about getting your patch into the 3.2.0b4
snapshots. If we get it in shortly, we'll probably have a beta release or
two to catch any portability problems.

--
-Geoff Hutchison
Williams Students Online
http://wso.williams.edu/

[htdig-dev] [ htdig-Patches-605517 ] fix for SSL patch to 3.1.6

[<noreply@so...>]

Patches item #605517, was opened at 2002-09-06 13:01
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304593&aid=605517&group_id=4593

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Vorlaender (martinv2)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for SSL patch to 3.1.6

Initial Comment:
I applied the SSL patch from ftp://ftp.ccsf.org/htdig-
patches/3.1.6/ssl.9 to the VMS port, and hit the following 
showstopper:
On platforms without a /dev/u?random device 
or an EGD daemon (e.g. VMS ;-), the SSL PRNG is seeded from a file. 
For this to work, the application must call RAND_load_file() or else 
a connect fails with an "PRNG not seeded" error message (new 
behaviour since OpenSSL 0.9.5). When I insert this call into 
htlib/Connection.cc's Connection::initSSL, SSL connections do 
work.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304593&aid=605517&group_id=4593

Re: [htdig-dev] OS X 10.2

[Jim Cole <greyleaf@yg...>]

Gilles Detillieux's bits of Thu, 5 Sep 2002 translated to:

>According to Jim Cole:
>> I think there is a bug in htnotify's readPreAndPostamble(). Both
>> htnotify_prefix_file and htnotify_suffix_file have a default
>> value of "", but the code only checks for NULL when examining the
>> values of prefixfile and suffixfile. The code then proceeds to
>> create ifstream objects using the default values. Finally, the
>> streams are checked with 'if (! in.bad())'; however the ifstream
>> constructor sets failbit, rather than badbit, when it is unable
>> to open the specified file. The result is that the code drops
>> into a while loop and starts extracting from an undefined stream
>> object.
...
>Yes, this was reported just a few weeks ago, and a patch was provided.
>See ftp://ftp.ccsf.org/htdig-patches/3.1.6/

Sorry. I somehow missed that post. However, even with the patch I
believe the code in both 3.1.6 and 3.2.x is incorrect. If the
name of a non-existent file was provided, the same problem with
infinite looping could occur. As I understand the standard, the
check of in.bad() is of no use with regard to whether the file
was opened successfully. If on the other hand in.good() is
checked, then it would ensure that neither badbit nor failbit is
set.

Jim

[htdig-dev] Questions about htdig-3.2.0b3/htcommon/defaults.cc

[Brian White <bwhite@st...>]

I was looking at defaults.cc and I was wondering if
it might be better managing the info as an XML file
and then using that as a basis for generating
defaults.cc and the HTML docs.

The fields are

struct ConfigDefaults
{
   char  *name;          // Name of the attribute
   char  *value;         // Default value
   char  *type;          // Type of the value (string, integer, boolean)
   char  *programs;      // Whitespace separated list of programs/modules 
using this attribute
   char  *block;         // Configuration block this can be used in (can be 
blank)
   char  *version;       // Version that introduced the attribute
   char  *category;      // Attribute category (to split documentation)
   char  *example;       // Example usage of the attribute (HTML)
   char  *description;       // Long description of the attribute (HTML)
};

I can see programming uses for  name, value, type and maybe programs.
I assume all the rest is just for documentation

It would be simple enough to write a perl script that
extracted the necesary fields to create defaults.cc,
that only had what was actually needed for the program,
and then something a bit cleverer written to create the
HTML pages.

( I just noticed the perl script that uses
   defaults.cc to generate the doc pages )

Advantages
   * It would put all the default info into a
     much easier to edit and documentable format
   * It would make it much clearer which values were
     required in the code and which were there
     for documentation.
   * It would reduce the size of the executable by
     about 80000 characters ( 80K or maybe 160 K)

Disadvantages
   * Part of the build process for exexcutabe would require
     perl to exist
   * The current system, be it a bit clunky to my eyes,
     does work, and does solve the problem of trying
     to maintain concurrently the code version and
     the documentation version of the attributes.
   * After rabbiting on like this I now have to decide
     if I willing to put my money where my mouth is.....

Regs

Brian





-------------------------
Brian White
Step Two Designs Pty Ltd
Knowledge Management Consultancy, SGML & XML
Phone: +612-93197901
Web:   http://www.steptwo.com.au/
Email: bwhite@...

Content Management Requirements Toolkit
112 CMS requirements, ready to cut-and-paste

Re: [htdig-dev] Adjustable logging patch.

[Brian White <bwhite@st...>]

At 09:10 6/09/2002, Gilles Detillieux wrote:
> > 2) If the issue is the portability of flock, would it be
> >     acceptable if I changed it over to using fcntl?
> >
> >      (Mr Google threw up the follwoing page which says that "fcntl() is the
> >       only POSIX-compliant locking mechanism, and is therefore the only
> >       truly portable lock"
> >
> >       http://www.erlenstar.demon.co.uk/unix/faq_3.html
> >       )
>
>Well, while going with POSIX-compliant locking would help with
>portability, I'm not sure all systems currently supported by 3.1.x
>are fully POSIX-compliant either, so it may be that some only support
>flock(), or even perhaps no locking at all.  Some configure tests for
>various locking schemes should be implemented, so the code uses what
>the system provides, or no locking at all if nothing appropriate is found.

I already have "locked" and "unlocked" versions of the code, managed by
an #ifdef - I would just have to add a  -D__NO_FILE_LOCKING__ or something
like that.

I assume this means I would need to create a patch for the configure
script - any tips on how to do that? Is that monster *really* maintained
solely by hand or is there some tools for it?

> > 3) It should be simple enough to create a patch that works with 3.2.x,
> >     judging by a quick look at the latest Display.cc in the CVS repository.
> >
> > I *would* like to get it rolled into 3.1.x if I can. I am
> > more than willing to make any changes required to make this
> > happen.
>
>I think it would be good to see this in the 3.2 CVS tree, with the
>appropriate configure tests.  I'm still a bit lukewarm on the addition
>of the "init" input parameter to htsearch.  It seems the absense of a
>"page" parameter would mean the same thing, wouldn't it?

You know, I hadn't even thought of that. The only disadvantage to it
is that it isn't explicit - I can see someone setting "Page=1" for their
initial search and wondering why their logging doesn't work. The only
way around this would be documentation, with notes

    1) Where the "page" parameter is discuseed
    2) Where the logging attributes are discussed
    3) In the FAQs

Otherwise - Yes! Perfect!

>As for 3.1.x, though, here are my thoughts.  I'm quite adament about
>not wanting to put out a 3.1.8 release.  So, that means I have to be
>very adament about getting 3.1.7 right, with no new bugs or portability
>problems.  To do that, I think I'm going to need to put my foot down as
>far as the feature freeze, and insist that only bug fixes go into 3.1.7,
>and no new features.  The only discussed new feature for 3.1.7 that I
>haven't completely ruled out yet is location_factor, because it's tied
>to some bug fixes in WordList::Word() anyway, and had been planned for
>3.1.6 but fell through the cracks.  I may drop this attribute anyway,
>and stick to just bug fixes.

Ok - my desire to get it into 3.1.x is based around the fact that
we have installed 3.1.6 at a large client site, with the AdjustableLogging
patch installed. In fact, it was written for their installation.
It makes long term support slightly easier if the product is *fully* off the
shelf.

However, that said - getting it into the 3.2 CVS tree means by the
time it ever becomes a genuine issue, a stable 3.2 release should
be available for use. I would be happy with that.



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

-------------------------
Brian White
Step Two Designs Pty Ltd
Knowledge Management Consultancy, SGML & XML
Phone: +612-93197901
Web:   http://www.steptwo.com.au/
Email: bwhite@...

Content Management Requirements Toolkit
112 CMS requirements, ready to cut-and-paste

Re: [htdig-dev] Adjustable logging patch.

[Joe R. Jah <jjah@cl...>]

On Thu, 5 Sep 2002, Gilles Detillieux wrote:

> Date: Thu, 5 Sep 2002 18:10:53 -0500 (CDT)
> From: Gilles Detillieux <grdetil@...>
> To: Brian White <bwhite@...>
> Cc: htdig-dev@...
> Subject: Re: [htdig-dev] Adjustable logging patch.
> 
> As for 3.1.x, though, here are my thoughts.  I'm quite adament about
> not wanting to put out a 3.1.8 release.  So, that means I have to be
> very adament about getting 3.1.7 right, with no new bugs or portability
> problems.  To do that, I think I'm going to need to put my foot down as
> far as the feature freeze, and insist that only bug fixes go into 3.1.7,
> and no new features.  The only discussed new feature for 3.1.7 that I
> haven't completely ruled out yet is location_factor, because it's tied
> to some bug fixes in WordList::Word() anyway, and had been planned for
> 3.1.6 but fell through the cracks.  I may drop this attribute anyway,
> and stick to just bug fixes.

Would you please list the patches you have already committed to CVS, and
those you may, so that we can carry over the rest as patches to 3.1.7
folder.  Here is the list as of: Thu Sep 5 17:38:47 PDT 2002:

Patch                        # of downloads
-----                        --------------
ssl.9                          193
timet_enddate.1                182
Makefile.0                      78
documentation.1                 68
metadate.0                      65
redirect.0                      51
documentation.2                 50
NUL.0                           47
AdjustableLoggingPatch.tar.gz   44
fileSpace.1                     42
titleSpace.0                    36
multiple-noindex.1              34
Date-viewing.0                  32
time_t.0                        27
gcc-3.1.0                       22
ExecutionTime.0                  9
ExternalParser-max_doc_size.0    7
htnotifyNull.0                   6

Regards,

Joe
-- 
     _/   _/_/_/       _/              ____________    __o
     _/   _/   _/      _/         ______________     _-\<,_
 _/  _/   _/_/_/   _/  _/                     ......(_)/ (_)
  _/_/ oe _/   _/.  _/_/ ah        jjah@...