According to Geoff Hutchison:
> I talked to Neal off-list, so I'd like to clarify as well. I think the
> three of us are thinking basically the same thing, but it doesn't help
> when we talk about "3.3" or "4.0." So let's talk about "how to get 3.2.0b4
> out soon."
Agreed. We can hammer out the details of later versions later. For now,
though, we need a reliable 3.2.0b4 out there. My only immediate concern,
which just occurred to me this morning, is the confusion caused by 18
months worth of 3.2.0b4 snapshots out there, incorporated into RPMs
and such. When a bug report mentions 3.2.0b4, will we be able to trust
that it's actually the official 3.2.0b4 release? Would it be helpful
to skip b4 and jump to b5?
> On Thu, 17 Oct 2002, Gilles Detillieux wrote:
> > 3) My own lack of time in being able to get the 3.1.6 fixes/updates
> > forward ported to 3.2.
>
> If you have a list of particular things, it would help significantly. I'll
> check through the mailing list, but if you have a list somewhere it'd save
> some time.
I haven't updated the list since I sent it to Jessica Biola back in August.
Here it is again...
--- ---
From: Gilles Detillieux <[EMAIL PROTECTED]>
Subject: Re: [htdig-dev] Features in 3.1.6 and not in 3.2.0b4?
To: [EMAIL PROTECTED] (Jessica Biola)
Cc: [EMAIL PROTECTED]
Date: Fri, 16 Aug 2002 17:19:43 -0500 (CDT)
According to Jessica Biola:
> Are there any features that are in 3.1.6 and not in
> 3.2.0b4? If so, could someone kindly provide a list
> of the features? (i.e. ignore_dead_servers)
I haven't yet compiled an exhaustive list of these. The sketchy list I
have so far is...
- multi-excerpt patch (max_excerpts attribute) for htsearch/Display.cc
- better handling of htdig -m option
- add startyear et al. to defaults.cc
- make startyear et al. handle relative date ranges in Display.cc
- fuzzy endings patch and updated english.0 file
- get updated external parser scripts into contrib directory
(fix eof handling bug in .pl scripts)
- list-all feature in htsearch for a query of * or prefix_match_character
- ignore_dead_servers attribute
- description_meta_tag_names attribute
- ignore_alt_text attribute
- translate_latin1 attribute, with hooks into SGMLCodec class
- search_rewrite_rules attribute
- anchor_target attribute
- search_results_contenttype attribute
- boolean_keywords attribute
- boolean_syntax_errors attribute
- multimatch_method attribute (still VERY buggy in 3.1.6 though)
The only way to get a really complete list is to go through the release
notes and ChangeLog for 3.1.6, and make sure that each of these things
(or something equivalent) is in the 3.2 CVS tree already.
--- ---
Note that some items in the list may already be in the 3.2 cvs. I just
haven't checked yet. Also, a close look at the 3.1.6 ChangeLog may reveal
bug fixes I've missed in both the list above and the 3.2 cvs.
> > library (iconv). I think Neal's idea of the zlib-WordDB-compression
> > retrofit has merit, if only to get an interim beta 4 out the door soon.
> > I see it as a quicker solution to the reliability issue.
>
> I think we're all on the same page here, though I'd like to see the patch
> first, obviously. I've been working on the mifluz merge because I think it
> needs to be done and b/c I can't see how we can ship a 3.2.0b4 with these
> database bugs. If there's a smaller bug-fix, that's great. :-)
Sounds like a plan!
> > The only other thing I see as essential for 3.2.0b4 is getting the
> > 3.1.6 changes in there. Otherwise, there'll be too much confusion
>
> I think there are a few remaining minor bugs which we should probably
> stomp along the way.
Yes, we should comb through the bug database for anything that's
tackleable and/or urgent enough to warrant working on for b4. As for
Gabriele's question about the Content-Encoding header handling in
HTTP/1.1, I'd say that depends. Is Content-Encoding header handling
optional in an HTTP/1.1 client, or is it fully up to the server's
discretion whether it is used. If HTTP/1.1 clients are required, by
the standard, to recongnize Content-Encoding, then I'd call it a bug
that htdig doesn't. If the standard makes it optional, then I'd think
there should be a way htdig can tell the server "I don't grok this."
> > Other side projects like defaults.xml are great, but this seems to be
> > shaping up to be a much bigger task that originally envisioned, what
>
> No offense to Gabriele, but I'd rather consider translations to the
> documentation _after_ we switch to an XML documentation setup.
>
> Personally, I'd consider switching to defaults.xml for 3.2.0b4 if I can
> see a patch in the near future. I'm willing to handle the documentation
> fixes by hand if I need to do it.
Again, sounds like a plan. My concern was that the whole translation
issue was going to affect the design of the XML DTD and coding for
defaults.xml, and it would take a while to nail that down too. If the
basic framework and the English version of the file can be readied in
time for b4, let's go with that, and fill in other languages later.
Another question to consider for this is, do we want all languages in
the same file, or do we want separate default.xml files for each one?
What about encodings? We'd need to handle different encodings for
different languages, and pass this encoding specification into the
generated HTML files. (Or is it all Unicode?) I know we don't need to
nail all this down now, but I thought I'd ask just in case these issues
affect the basic design we need to get in place for 3.2.0b4.
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/
Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada)
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
htdig-dev mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/htdig-dev
