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: <[EMAIL PROTECTED]>
>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: [EMAIL PROTECTED]
Content Management Requirements Toolkit
112 CMS requirements, ready to cut-and-paste
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
htdig-dev mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/htdig-dev
