According to Alexis Mikhailov:
> Well, first I wanted to ask developers will they be willing to
> include all this changes. If some change is to be included
> I would like to commit it to CVS. If some other change is not
> satisfactory I would like to be given some hint how to rework it.
As Geoff mentioned earlier, we just want to bring you up to speed.
We welcome contributions from users, but there are a few tips we have
that make it a whole lot easier for everyone to work together on this.
- On the subject of whether the developers will be willing to include
changes, there are a few things that make the approval quicker. The main
thing is to submit changes separately for consideration. Large, "omnibus"
patches may be easier from the submitters perspective, but it puts the
onus on the developers to figure out what all the individual changes in
the patch do, and what their potential impact will be on portability,
performance, and reliability. Documentation on each individual change
also helps a lot in that regard.
- On the subject of CVS access, you should first be aware of the
status of htdig's CVS repository. There are currently 3 active forks.
There's the main htdig3 tree, in which future 3.2 development occurs.
There's htdig-3-1-x, which is currently being prepared for a release
of 3.1.4, and finally there's htdig-3-2-x, which is being prepared for
3.2.0b1, the first beta release of the 3.2 development.
The 3.1.4 release will be strictly a maintenance release - only bug fixes
and simple, well tested and often requested enhancements. This is the
one I'm focussing on, and I'm evaluating contributions and bug reports
primarily with 3.1.4 in mind. While there isn't an official feature
freeze in place, I'm being pretty strict about what I'm putting in
there myself.
The 3.2.0b1 release is under a feature freeze, which means only bug fixes
go in unchallenged. Anything else must go to a vote on the htdig3-dev
mailing list.
Just about anything goes with htdig3, for future 3.2 releases, but you
won't see any changes there released for a while, and anything you put in
there may get hacked to bits by other developers if they don't like it,
or if they replace the modules you changed with something else.
Anything that gets committed to any fork of the tree should be accompanied
by a ChangeLog entry, and separate fixes or features must be committed
separately - that's why omnibus patches are hard to deal with.
And in another message, Alexis wrote...
> Gilles Detillieux wrote:
> > 1) htcommon/DocumentDB.cc & htdig/Retriever.cc: allow file:... as well
> > as http:... URLs. (This doesn't change anything in htlib/URL.cc, so I'm
>
> I's true.
As I said, most of this should be in 3.2.0b1 already. Perhaps you could
have a look at a snapshot, or load the htdig-3-1-x tree from the CVS
repository, and see if anything was missed. (Some of the checks for
"http:" were stripped out entirely in 3.2.)
> > 2) htdig/HTML.cc: add support for an ignore_noindex attribute. This is
> > undocumented and no default is defined, but I think the behaviour is
> > pretty obvious from the code. I'd question the desirability/need for
> > this, but it seems harmless enough. The value should be set in a static
> > variable, though, to minimise performance impact. I'd call this a work
> > in progress.
>
> This variable was added to allow index of local files with NOINDEX tag.
> For example, all Qt documentation files contain this tag. I thought
> it would be not interesting to remove this tag in every file by hand,
> so I created this variable. Forgot about default value though.
Geoff & I have reservations about this. I think it should be discussed
further.
> > 3) htdig/Retriever.cc & htdig/Server.cc: modified to allow local file
> > access to persist even if the HTTP server is down. Looks good to me.
Unless anyone objects, I'd like this to go into 3.1.4. For 3.2.0b1, we
need a vote. Here's my +1!
> > 4) htdig/htdig.cc & htlib/String.cc: allow htdig to read URL list from
> > stdin if htdig given an argument of "-". The >> operator added to the
> > String class uses a lot of stuff I've never seen before, so I don't know
> > how to judge it for myself. It seems more complicated that it would
> > need to be for the simple task at hand - all you need to do is load all
> > of stdin into one string - but I guess the line by line approach would
> > allow bigger lists (less string overhead). Undocumented.
>
> Was copied from ba_string.c (IIRC) (STL's string class). Though modified
> to allow only '\n' to go as end of string.
I'm still concerned about portability to non-GNU C++ compilers &
libraries. It also seems unnecessary to me. Most line input in htdig
is done via the getline() method, which wouldn't complicate things much
in htdig.cc, and wouldn't require new code in String.cc - I'd say go
for consistency. I'm also concerned about Joe's segmentation violation
in the String class, and I'll wait to hear back from Joe about this.
I'll see if I can find the time to put together a simpler implementation
of this for 3.1.4.
> > 5) htlib/String.cc: fix a bug in write() method, which is currently unused.
Innocuous bug fix. I'll put it into 3.1.4 & 3.2.0b1.
> > 6) htlib/cgi.cc & htsearch/htsearch.cc: add a -a option to htsearch, to
> > add name=value parameters to those in query string. This is undocumented
> > as well. I'm not sure how it relates to the other changes, but it seems
> > simple enough.
>
> This option was added to simplify calling of htsearch from external
> program. Of course it was possible to set enviroment variables to
> emulate CGI call, but it seemed unnecessary complicated.
Understood, but I think Torsten's method, which I adapted for 3.1.4 &
3.2.0b1 is a better approach. If the separate -a option is still wanted
after these releases are out, then I'd say it could go in future releases.
> > 7) htsearch/htsearch.cc: set alarm() time earlier in execution than was
> > done before. Didn't know that the initial processing could lead to hangs.
>
> It didn't lead. I've moved it together with moving declaration of input
> variable in case constructor of cgi class do something that could hang.
Something like reading POST data that doesn't get sent in its entirety.
Good thinking! So this change is indeed tied to change (6) above - that
was not clear to me at all. So, if 6 goes in, 7 should as well.
> > 8) htsearch/Display.cc: compare nPages to maximum_pages earlier than was
> > done before, presumably so PAGES variable won't be allowed to exceed it.
>
> Also to not display '1', '2' etc. buttons in the end of page if
> maximum_pages = 1.
Yes, that too! This is definitely a bug fix, and I'll put it in.
> > I'm all for these fixes, but some documentation explaining the less
> > clear aspects, or even a note explaining the rationale for these,
> > would be appreciated.
>
> As I have writen in the letter with patch, all this changes were done
> to allow using of htdig as index engine to KDevelop. I tried to make
> changes as general as possible to be useful not only to KDevelop.
Yes, I do realise that was your motivation for all the changes, but
they are still several separate changes which must be considered (and
explained) independently. To make them generally useful, we need to
document how and why you'd used each one, especially the optional ones
like ignore_noindex, htdig -, and htsearch -a parm=value.
--
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
