Hi, Rainer

On 15 Nov 2000, at 1:00, Rainer.Scherg@rexroth.de wrote:

> Hi Jose!
> 
> Thinking again about "Descriptions", I would not distinguish
> between HTML or other doc-types.
> 
> Normally, you want to have descriptions switched on or not.
> IMO it's enough to have a config parameter describing the
> length of the description being stored into the database.
> 
> I have to look on the code, but - as a first guess - the 
> descr. field can be stored along with the path data. So
> we only need a routine to gather and store the descr. info.
> 

Sure, it may not be difficult to add. 

> The add. amount of uncompressed data is also acceptable:
> 
>    10000 files  x 200 bytes  would be @2 megs plus
>    add pointer storage if needed.
> 
> When storing the data into the existing swish database, we
> need only an add. config statement:
> 
>   StoreDescription <count>      # 0 = default = off
> 

So, a document may contain both title and description, right?
I would also like the possibility that the description can be a field 
(Metaname). What about:

StoreDescription <field>|size

For a field (the filed may be enclosed by <>). Eg:

StoreDescription <myfield>

Just for size. Eg:

StoreDescription 400

What do you think?

> 
> ---------
> 
> 
> Another topic to discuss:
> 
>   Since filtering has been implemented I got the still existing
>   problem, that swish-e cannot retrieve the file size.
>   This is because filtering is implemented as PIPE stream.
> 

Well, in fact that was the filter bug of 2.1.4: it read the size and
then, if 0, did nothing (I applied a quick patch to read_stream 
function to avoid this situation).

>   Saving a filteroutput to a tempfile would not resolve the
>   problem, because you don't get the size of the original file.
> 
>   I would like to see the query for the filesize removed from the
>   countwordsXXX-routines and placed outside.
> 
>   This would fix the bug, but brings a small performance penalty
>   due the extra request for file information. This routine
>   could also be used e.g. to retrieve and store last modification
>   dates, etc.
> 
>  Any opinions?
> 
I totally agree with you. There must be an additional parameter to
countwordsXXX-routines (the size of the data). The modification is 
simple for normal files but need some extra overhead for filtered 
files.

I can modify it for the next release.

cu
Jose