Menu
▾
▴
xapian-discuss — Mailing list for discussions about the Xapian project
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(27) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(14) |
May
|
Jun
(5) |
Jul
(15) |
Aug
(13) |
Sep
(15) |
Oct
(33) |
Nov
(15) |
Dec
(20) |
| 2003 |
Jan
(14) |
Feb
(15) |
Mar
(22) |
Apr
(43) |
May
(41) |
Jun
(19) |
Jul
(66) |
Aug
(16) |
Sep
(40) |
Oct
(28) |
Nov
(8) |
Dec
(39) |
| 2004 |
Jan
(63) |
Feb
(47) |
Mar
(202) |
Apr
(43) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Olly B. <ol...@su...> - 2004-04-26 19:23:13
|
We're moving the Xapian lists (xapian-discuss, xapian-devel, and xapian-commits) from sourceforge to lists.xapian.org. The major immediate benefit is that this should eliminate the long delays in relaying messages that we currently sometimes experience. The new list addresses are: xap...@li... xap...@li... xap...@li... And the mailman list pages are at: http://lists.xapian.org/mailman/listinfo You probably only need to update your address book, and perhaps mail filtering rules. James copied the subscriber lists over during the weekend, so you are automatically subscribed to the new lists unless you subscribed very recently. I'll send out a message to the new lists shortly - if you don't get that, you should investigate. Everyone will shortly be removed from the old lists, so you should get a bounce if you accidentally use an old list address. It doesn't appear to be possible to do anything better - sourceforge don't allow much control over list addresses. Cheers, Olly |
|
From: Donald F. <df...@la...> - 2004-04-26 13:46:13
|
I still get the problem on a small data-set, and have included code which demonstrates this (test-xapian2.py attached). I am using Xapian 0.7.5 The one thing I can think of is that the precentage weight of the match in the offending query (for all matching documents) is 1. Program output: ski NOT "jet skiing" ==================== 0 (4, 0.34119466972887913, 0, 1) skiing skiing skiing skiing skiing skiing skiing 1 (1, 0.25602990915291085, 1, 1) Alpine ski : 230 km of ski runs 2 (2, 0.21180656120831717, 2, 1) Jet skiing (3000 m away) ski === 0 (4, 0.34119466972887913, 0, 99) skiing skiing skiing skiing skiing skiing skiing 1 (1, 0.25602990915291085, 1, 75) Alpine ski : 230 km of ski runs 2 (2, 0.21180656120831717, 2, 62) Jet skiing (3000 m away) Regards, Donald Fisk ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ |
|
From: Donald F. <df...@la...> - 2004-04-26 11:08:04
|
Olly Betts wrote: > I've checked Xapian::QueryParser and it handles 'beer NOT "orangejuice"' as I'd expect. > I've also tried a few queries of the form 'X NOT "Y Z"' but they all work as I'd expect. Thanks for your prompt reply. The process of santizing the data somehow caused the bug to go away. Logically, the two cases (real and sanitized) are identical. The difference is in the size of the data set and perhaps some property of its contents. What I'm going to do now is start at the sanitized data, and gradually work towards the real data, to find out at what point it breaks. Then I'll get back to you again. Even if it's not a bug in Xapian, it is still surprising behaviour and could do with being documented. Regards, Donald ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ |
|
From: Olly B. <ol...@su...> - 2004-04-23 16:14:55
|
On Fri, Apr 23, 2004 at 04:57:20PM +0100, Donald Fisk wrote:
> I've just joined. I'm using Xapian with Python and have run into a
> problem (bug?).
>
> In queries, NOT doesn't work with phrases containing more than one word.
> The results I get are
>
> Query (number of matching documents)
>
> 'beer' (23)
> 'wine' (168)
> 'beer OR wine' (186)
> 'beer AND wine' (5)
> 'beer -wine' (18)
> 'beer NOT wine' (18)
> 'beer NOT beer' (0)
> 'beer NOT "beer"' (0)
>
> So far, so good. But now,
>
> 'beer NOT "root beer"' (23)
> 'beer NOT "orange juice"' (23)
>
> Initially, I thought it was because "root beer" contained the word
> "beer", but this
> is contradicted by the second case. (Some of the 23 documents matched
> contain the
> phrase "root beer", and others contain "orange juice".)
>
> Is there (a) something I'm doing wrong (and if so, what?)
> (b) a bug fix
> (c) a work-around?
I've checked Xapian::QueryParser and it handles 'beer NOT "orange
juice"' as I'd expect. I've also tried a few queries of the form
'X NOT "Y Z"' but they all work as I'd expect.
So I'm a little puzzled what's going wrong. Could you post the
python scripts you're using?
Cheers,
Olly
|
|
From: Donald F. <df...@la...> - 2004-04-23 15:57:44
|
Hi, I've just joined. I'm using Xapian with Python and have run into a problem (bug?). In queries, NOT doesn't work with phrases containing more than one word. The results I get are Query (number of matching documents) 'beer' (23) 'wine' (168) 'beer OR wine' (186) 'beer AND wine' (5) 'beer -wine' (18) 'beer NOT wine' (18) 'beer NOT beer' (0) 'beer NOT "beer"' (0) So far, so good. But now, 'beer NOT "root beer"' (23) 'beer NOT "orange juice"' (23) Initially, I thought it was because "root beer" contained the word "beer", but this is contradicted by the second case. (Some of the 23 documents matched contain the phrase "root beer", and others contain "orange juice".) Is there (a) something I'm doing wrong (and if so, what?) (b) a bug fix (c) a work-around? Regards, Donald ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ |
|
From: Eric R. <eb...@tc...> - 2004-04-21 18:56:31
|
On Apr 21, 2004, at 2:21 PM, James Aylett wrote: > I notice that something like this has changed in 0.8.0: > > * Throw an exception when an empty query is used to build in the > binary operator Query constructor (previously this caused a > segfault. Added regression test. wonderful! > So it should now except out of the top of main() rather than core dump > out of the middle. So the above program fragment will still fail, but > in a way that can be trapped. > > (It's probably worth you checking against 0.8.0 explicitly, of course.) I'll do that. eric |
|
From: James A. <jam...@ta...> - 2004-04-21 18:21:29
|
On Wed, Apr 21, 2004 at 02:01:29PM -0400, Eric Ridge wrote:
> This C++ code demonstrates the problem:
>
> int main(int argc, char **argv)
> {
> Query left;
> Query right("test");
> Query *q = new Query(Query::OP_AND, left, right);
>
> cout << q->get_description() << endl;
> return 0;
> }
>
> and dumps on this line:
> Query *q = new Query(Query::OP_AND, left, right);
I notice that something like this has changed in 0.8.0:
* Throw an exception when an empty query is used to build in the
binary operator Query constructor (previously this caused a
segfault. Added regression test.
So it should now except out of the top of main() rather than core dump
out of the middle. So the above program fragment will still fail, but
in a way that can be trapped.
(It's probably worth you checking against 0.8.0 explicitly, of course.)
J
--
/--------------------------------------------------------------------------\
James Aylett xapian.org
ja...@ta... uncertaintydivision.org
|
|
From: Eric R. <eb...@tc...> - 2004-04-21 18:01:37
|
I discovered this thanks to my JNI library and a few silly users.
This C++ code demonstrates the problem:
int main(int argc, char **argv)
{
Query left;
Query right("test");
Query *q = new Query(Query::OP_AND, left, right);
cout << q->get_description() << endl;
return 0;
}
and dumps on this line:
Query *q = new Query(Query::OP_AND, left, right);
If you have a Query whose length is zero, and you try to use it as part
of a sub-query, Xapian will dump core. The docs say that the default
ctor "makes an empty query which matches no documents". Probably the
mset of the Query should just be empty, or it could depend on the
operator: "nothing" OR "something" could return something, whereas
"nothing" AND "something" could return nothing. Just thinking out loud
here.
Anyways, it happens on Linux and OS X, so it's not just my Mac being a
pain. Here's a backtrace from gdb.
(gdb) bt
#0 0x01542ef4 in
Xapian::Query::Internal::add_subquery(Xapian::Query::Internal const&)
(this=0x4001f0, subq=@0x0) at omqueryinternal.cc:806
#1 0x0153d3f0 in Xapian::Query::Query(Xapian::Query::op, Xapian::Query
const&, Xapian::Query const&) (this=0x4001e0, op_=OP_AND,
left=@0xbffffc50, right=@0xbffffc60) at ../include/xapian/base.h:148
#2 0x00002e28 in main ()
#3 0x00002a80 in _start (argc=1, argv=0xbffffd80, envp=0xbffffd88) at
/SourceCache/Csu/Csu-46/crt.c:267
#4 0x000028f4 in start ()
Let me know if I can provide further details.
eric
|
|
From: Olly B. <ol...@su...> - 2004-04-20 22:43:02
|
I've uploaded Xapian 0.8.0: http://www.xapian.org/download.php Details of the changes are here: http://www.xapian.org/news.php Enjoy! Cheers, Olly |
|
From: Olly B. <ol...@su...> - 2004-04-15 14:11:59
|
On Thu, Apr 15, 2004 at 04:02:19PM +0200, Robert Pollak wrote:
> When Enquire::get_mset is called, certainly only a part of the total
> result set is computed. Is this partial set reused for additional
> get_mset calls?
No.
> I other words:
> When calling get_mset(1000,10), then get_mset(1010,10), does the second
> call take approximately the same time than the first one, or is it much
> faster?
It'll be faster in general, but only because the appropriate disk blocks
will be cached by the OS.
> And what about a subsequent call of get_mset(990,10)?
Similarly.
> If it takes the same time, I may have to set the maxitems argument much
> higher, keep the resulting MSet, and present only part of it to the
> user.
> (On the other hand, setting maxitems high could cause a huge performance
> hit when people are looking only at the first 10 results ...)
We discussed providing an interface which could do this behind the
scenes - either doing a search or using cached results as needed
with a uniform API. But it's not happened yet...
You could look at how many pages people typically view and base your
initial search size on that.
> How does Omega do this when the user clicks "Next"? It seems there is no
> such internal search result state kept.
There isn't. Keeping state in a CGI is rather messy, so we don't
currently keep more than the minimum (and that's passed using form
parameters rather than keeping anything server side).
So Omega runs the query afresh each time.
Cheers,
Olly
|
|
From: Robert P. <rob...@fa...> - 2004-04-15 14:02:49
|
Hi Olly and the list - (please forgive me if I am emitting nonsense ...) When Enquire::get_mset is called, certainly only a part of the total result set is computed. Is this partial set reused for additional get_mset calls? I other words: When calling get_mset(1000,10), then get_mset(1010,10), does the second call take approximately the same time than the first one, or is it much faster? And what about a subsequent call of get_mset(990,10)? If it takes the same time, I may have to set the maxitems argument much higher, keep the resulting MSet, and present only part of it to the user. (On the other hand, setting maxitems high could cause a huge performance hit when people are looking only at the first 10 results ...) How does Omega do this when the user clicks "Next"? It seems there is no such internal search result state kept. -- Robert Pollak GPG Key ID: 748646AD |
|
From: alessandro b. <a.b...@sy...> - 2004-04-13 14:53:25
|
Thank a lot , probably that is the reason . I 'll try soon and I'lle let you know. Thank Alex ----- Original Message ----- From: "Olly Betts" <ol...@su...> To: "alessandro bonvicini" <a.b...@ci...> Cc: <xap...@li...> Sent: Tuesday, April 13, 2004 4:08 PM Subject: Re: [Xapian-discuss] OP_PHRASE > On Tue, Apr 13, 2004 at 01:57:49PM +0200, alessandro bonvicini wrote: > > But with simplesearch the result is always 0 , the same phrese in omega give > > a match inside simplesearch not. > > Are there any capital letters or accented characters in your query? > Omega handles both, but simplesearch doesn't. > > Cheers, > Olly > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Xapian-discuss mailing list > Xap...@li... > https://lists.sourceforge.net/lists/listinfo/xapian-discuss > |
|
From: Olly B. <ol...@su...> - 2004-04-13 14:08:43
|
On Tue, Apr 13, 2004 at 01:57:49PM +0200, alessandro bonvicini wrote:
> But with simplesearch the result is always 0 , the same phrese in omega give
> a match inside simplesearch not.
Are there any capital letters or accented characters in your query?
Omega handles both, but simplesearch doesn't.
Cheers,
Olly
|
|
From: alessandro b. <a.b...@ci...> - 2004-04-13 11:58:18
|
Hi all, I am trying to build my first query interface with xapian , and so i have slightly modified simplesearch.cc changing OP_OR to OP_PHRASE. I' m using the same db creted with omindex and queried by omega. By omega it work well ,i can retrieve document with the phrase match. But with simplesearch the result is always 0 , the same phrese in omega give a match inside simplesearch not. The same happen if i surround the phrase with " or '. The documents in the db are italian, but the stemming is the some , english i suppose, in omega and in simplesearch. Any ideas to investigate. Thank a lot in advance Alex |
|
From: Olly B. <ol...@su...> - 2004-04-13 11:01:19
|
On Tue, Apr 13, 2004 at 11:57:18AM +0100, Olly Betts wrote:
> And trying to page past 27 would return an empty page, so Omega does
> the most something thing and shows the last page.
Erm - "most sensible thing".
Cheers,
Olly
|
|
From: Olly B. <ol...@su...> - 2004-04-13 10:57:29
|
On Mon, Apr 12, 2004 at 10:11:42PM -0400, Steven McClellan wrote:
> The search show 291 matches
Actually, it shows "about 291 matches". This figure is an approximation.
> and after paging through to get to the last page
> - page 30, it will show that there are now 267 matches
And now it says "exactly 267 matches". This is the correct figure.
What happens is that the matcher doesn't consider every possible
document - if it can ignore documents which can't possibly achieve
a high enough score to make it into the top N, it can save time.
So on pages 1-26, Omega doesn't know the exact number of matches.
Xapian calculates a likely approximate value - 291.
Now page 27 is only a partial page, so at this point we know how
many matches there are exactly.
And trying to page past 27 would return an empty page, so Omega does
the most something thing and shows the last page.
> This is the same for all multiple word searches, but works fine if you
> are only using one search term.
Yes, if you only have one term, the number of matches is the same as the
term frequency so is always exact.
> I know that the last documents are the least relevant but I know that
> somebody will try this.
If this is a concern to you, you can pass the CGI parameter MINHITS
which forces the matcher to do more work and ensures that any number
of matches less than MINHITS will be exact. So MINHITS=1001 will
ensure that nobody sees the effect you've noticed until at least
page 101. The price you pay is that most searches will be a little
slower. MINHITS should probably be available as an omegascript command
as you might want to set it relative to the current page...
Cheers,
Olly
|
|
From: Steven M. <st...@mc...> - 2004-04-13 02:11:28
|
I found something that seems a little strange to me and would like to = see if I can get some clarification. I found that if I do a multiple word = search using Omega that the page count of the pages are getting out of sync. = This behavior is easily duplicated on the Xapian site by searching for the = terms 'test' and 'word' (typing test word, not test and word - use a space to separate the two). Leave the default to match any word and then do the search. =20 The search show 291 matches and after paging through to get to the last = page - page 30, it will show that there are now 267 matches and the page = numbers are screwed up and page 30 has now become page 27. I have to step back = a page to page 26 in order for the page 30 button to show up again. = Clicking on the last page (page 30) will invoke the strange behavior again. This = is the same for all multiple word searches, but works fine if you are only using one search term. =20 I know that the last documents are the least relevant but I know that somebody will try this. =20 Thanks, =20 -Steve |
|
From: Olly B. <ol...@su...> - 2004-04-12 22:57:46
|
On Tue, Apr 13, 2004 at 12:03:01AM +0200, alessandro bonvicini wrote:
> After indexing tried omega.exe from command line:
> $ ./omega.exe 'P=Cambi di riferimento del 19 gennaio 1999 rilevati
> a titolo indicativo, secondo le procedure stabilite nell'ambito del
> Sistema e
> uropeo delle Banche centrali e comunicati dalla Banca d'Italia.'
> HITSPERPAGE=10 > test.html.
> It seems to me that this query is not a "phrase query" but a probabilitstic
> one.
> Can you say me how specify a phrase query on command line?
You specify a phrase query using double quotes - e.g. "a phrase query"
It's the same whether you're running on the command line or as a CGI,
but from the command line you need to worry about quoting to protect
the query from the shell.
Assuming you're running omega from cygwin's sh or bash, this should work:
./omega.exe 'P="a phrase query"' HITSPERPAGE=10 > test.html
If it's the NT command prompt, quoting is different. I *think* you'd
need this:
.\omega.exe "P=\"a phrase query\"" HITSPERPAGE=10 > test.html
Cheers,
Olly
|
|
From: alessandro b. <a.b...@sy...> - 2004-04-12 22:03:05
|
Hi all, I am very asthonished by the quality of xapian/omega. I really want to thank all of you, i think that xapian is a precious piece of software. I tried to test it on a 500 megabytes html document, the index process was long (8 hours) but the response time are no more long than 2/3 second. I am trying it on cygwin windowsxp laptop , 512 megabyte and celeron 2.4 (it a slow machine, but good to test software quality) . After indexing tried omega.exe from command line: $ ./omega.exe 'P=Cambi di riferimento del 19 gennaio 1999 rilevati a titolo indicativo, secondo le procedure stabilite nell'ambito del Sistema e uropeo delle Banche centrali e comunicati dalla Banca d'Italia.' HITSPERPAGE=10 > test.html. It seems to me that this query is not a "phrase query" but a probabilitstic one. Can you say me how specify a phrase query on command line? Thank a lot in advance , and thank again for this software Alex |
|
From: Arjen v. d. M. <ar...@gl...> - 2004-04-12 21:36:09
|
On 12-4-2004 22:52, Olly Betts wrote: > The amount of data pushed across the network could be greatly reduced - > omega always asks for at least 1000 matches (unless you pass a smaller > value for MINHITS) and at present this means it'll always pass 1000 > matches across from each remote backend (unless fewer than 100 documents > match with that backend). From a test I did, the current approach was even slower on a localhost-connection. And it appeared that it was sending a lot of data across the network. So that was why we took omega via xinetd, instead of local omega's and a remote database. But it was quite a while ago when I tested that. > If MINHITS was pushed into the matcher, we'd only need to return the > number of documents needed - for a standard search, that's 10, so > 100 times less traffic (well, not quite as there's other info to > pass too). > > We could also be smarter if there's only a single remote database in > use. Then we can reduce the traffic if the user asks for page 10 > to just the hits from that page (which we can't do if we need to > produce those hits from merging two or more msets). It'd be nice to see if that was possible, but our current approach works quite nice. So there is no need to hurry anything, just for us :) Best regards, Arjen van der Meijden |
|
From: Olly B. <ol...@su...> - 2004-04-12 20:57:32
|
On Mon, Apr 12, 2004 at 12:17:22PM +0200, Arjen van der Meijden wrote:
> Actually we first called omega with the parameters on the commandline
> (so omega P=... DB=... etc). And used that as a pipe-command of which we
> only read the output of omega (php didn't even have two-way pipes).
>
> But we reworked our setup to allow a remote server to handle the
> searches. Since then we use the omega-executable as the executable for
> xinetd, which is basically a tcp-wrapper around stdin and stdout of
> omega. It works quite nice (although application startup takes quite a
> bit of the time).
> That works - in our setup - much better than the remote-database of
> xapian, since that tries to send the entire resultset along the network
> and has the client sort that result and such. That could lead to a few
> megabytes of data along the network for a single query...
The amount of data pushed across the network could be greatly reduced -
omega always asks for at least 1000 matches (unless you pass a smaller
value for MINHITS) and at present this means it'll always pass 1000
matches across from each remote backend (unless fewer than 100 documents
match with that backend).
If MINHITS was pushed into the matcher, we'd only need to return the
number of documents needed - for a standard search, that's 10, so
100 times less traffic (well, not quite as there's other info to
pass too).
We could also be smarter if there's only a single remote database in
use. Then we can reduce the traffic if the user asks for page 10
to just the hits from that page (which we can't do if we need to
produce those hits from merging two or more msets).
Cheers,
Olly
|
|
From: Arjen v. d. M. <ar...@gl...> - 2004-04-12 10:20:26
|
On 12-4-2004 2:40, Olly Betts wrote: > Ah yes - we have to send a Content-Type: header, or we're violating the > CGI spe (unless we send Location: or Status: instead). > > A mode suitable for use from another process could be created by reworking > the old test mode where the parameters are passed on stdin, one per > line. That's much better suited to use by another program as there are > no worries about quoting arguments to protect them from the shell > (failing to do so is a common class of security hole). > > The wrinkle is that it's fiddlier to pipe both input to and output from > a process in many languages. There're no deadlock problems here as you > won't get any output until all the input has been sent, but you couldn't > just use popen() in C/C++ for example. > > Or it could be enabled with an omegascript command, but it really seems > this should be orthogonal to the template being used. > > Or perhaps with a command line switch. Maybe that's the best > compromise. Actually we first called omega with the parameters on the commandline (so omega P=... DB=... etc). And used that as a pipe-command of which we only read the output of omega (php didn't even have two-way pipes). But we reworked our setup to allow a remote server to handle the searches. Since then we use the omega-executable as the executable for xinetd, which is basically a tcp-wrapper around stdin and stdout of omega. It works quite nice (although application startup takes quite a bit of the time). That works - in our setup - much better than the remote-database of xapian, since that tries to send the entire resultset along the network and has the client sort that result and such. That could lead to a few megabytes of data along the network for a single query... But having that application as the backend for xinetd forces us to have "some sort of protocol", the http-header messes up that protocol, especially since it is at the front of the resultset (ok, we could skip it, but that is the other way around of course) Best regards, Arjen van der Meijden |
|
From: Olly B. <ol...@su...> - 2004-04-12 00:41:19
|
On Sat, Apr 10, 2004 at 07:08:20PM +0200, Arjen van der Meijden wrote:
> On 10-4-2004 17:51, Olly Betts wrote:
> >On Fri, Apr 09, 2004 at 03:02:54PM +0200, Arjen van der Meijden wrote:
> >
> >>Can you change that behavior, to not force a header on the cli ?
> >
> >The command line mode for Omega is primarily intended to allow testing
> >and debugging - it's much easier to attach a debugger to a command line
> >process than a CGI one. If we start making behaviour conditional on
> >whether we're running from CGI or the command line, it would get in
> >the way of such use.
>
> Well, it's also a nice way to use it as a backend process, instead of a
> frontend application. It saves a lot of hassle to create your own
> "omega-like" application. But HTTP-headers on the command line or at a
> pipe are a bit odd :)
> [...]
> We don't use the XML-template, I was referring to the Content-Type
> header, which is always put on top of the output of omega. Even if there
> is no $httpheader{}-command.
Ah yes - we have to send a Content-Type: header, or we're violating the
CGI spe (unless we send Location: or Status: instead).
A mode suitable for use from another process could be created by reworking
the old test mode where the parameters are passed on stdin, one per
line. That's much better suited to use by another program as there are
no worries about quoting arguments to protect them from the shell
(failing to do so is a common class of security hole).
The wrinkle is that it's fiddlier to pipe both input to and output from
a process in many languages. There're no deadlock problems here as you
won't get any output until all the input has been sent, but you couldn't
just use popen() in C/C++ for example.
Or it could be enabled with an omegascript command, but it really seems
this should be orthogonal to the template being used.
Or perhaps with a command line switch. Maybe that's the best
compromise.
Cheers,
Olly
|
|
From: Arjen v. d. M. <ar...@gl...> - 2004-04-10 17:10:59
|
On 10-4-2004 17:51, Olly Betts wrote:
> On Fri, Apr 09, 2004 at 03:02:54PM +0200, Arjen van der Meijden wrote:
>
>>On 10-3-2004 15:34, Olly Betts wrote:
>>
>>>In this case, it's probably because Omega currently always sends
>>>"Content-Type: text/html". 0.8.0 will add the "$httpheader" command to
>>>Omegascript, so I'll fix the xml template to use this to return
>>>"Content-Type: text/xml" instead.
>>
>>Can you change that behavior, to not force a header on the cli ?
>
>
> The command line mode for Omega is primarily intended to allow testing
> and debugging - it's much easier to attach a debugger to a command line
> process than a CGI one. If we start making behaviour conditional on
> whether we're running from CGI or the command line, it would get in
> the way of such use.
Well, it's also a nice way to use it as a backend process, instead of a
frontend application. It saves a lot of hassle to create your own
"omega-like" application. But HTTP-headers on the command line or at a
pipe are a bit odd :)
>>Or at least allow the header to be disabled?
>
>
> It can be - just remove the $httpheader{...} line from the omegascript
> template. The xml template is really just an example, and you'll
> generally want to customise it - for example, you should remove the
> topterms stuff if you aren't using it as it takes a significant time to
> calculate the topterms.
We don't use the XML-template, I was referring to the Content-Type
header, which is always put on top of the output of omega. Even if there
is no $httpheader{}-command.
I've removed the code which prepends that header for now from query.cc,
but I don't think that is the best way.
Perhaps a nicer way is to not prepend a header if nothing is done and
still allow the $httpheader{}-command to override that default?
Best regards,
Arjen van der Meijden
|
|
From: Olly B. <ol...@su...> - 2004-04-10 16:01:28
|
On Fri, Apr 09, 2004 at 03:02:54PM +0200, Arjen van der Meijden wrote:
> On 10-3-2004 15:34, Olly Betts wrote:
> >In this case, it's probably because Omega currently always sends
> >"Content-Type: text/html". 0.8.0 will add the "$httpheader" command to
> >Omegascript, so I'll fix the xml template to use this to return
> >"Content-Type: text/xml" instead.
>
> Can you change that behavior, to not force a header on the cli ?
The command line mode for Omega is primarily intended to allow testing
and debugging - it's much easier to attach a debugger to a command line
process than a CGI one. If we start making behaviour conditional on
whether we're running from CGI or the command line, it would get in
the way of such use.
> Or at least allow the header to be disabled?
It can be - just remove the $httpheader{...} line from the omegascript
template. The xml template is really just an example, and you'll
generally want to customise it - for example, you should remove the
topterms stuff if you aren't using it as it takes a significant time to
calculate the topterms.
Cheers,
Olly
|
