OVERVIEW

This pages is intended to give users of Swish-e an idea of the changes to come, to foster discussion of the direction of Swish-e, and a place where developers can map out new ideas.

None of this is written in stone. Any of the developers can write their ideas in this document, but that doesn't mean it will actually happen ;).

UTF-8 support

Supporting Unicode basically requires a full re-write of all the code.

drop expat-based parsers, require libxml2

This might simplify the code somewhat as well.

Support Incremental Indexing

The Swish-e index structure currently makes it difficult to do incremental indexing, range limiting, and presents limits to indexing due to memory requirements. A database may solve some of these issues, at possibly a cost of performance.

Swish-e has been linked with Berkeley DB. Although much slower in indexing, this may allow incremental indexing. Currently, the idea is to offer both database backends.

UPDATE: Mon Nov 8 15:07:59 CST 2004 (karman@cray.com)

This feature is in the 2.5 branch already. What kind of requirements do we have to label it 'stable'?

Split code into Search and Indexing code

There may be a small benefit from creating a smaller search-only program. CGI scripts may be faster, and the code would be smaller for those that want to embed Swish-e in to other applications.

Currently, linking libswish-e into a program adds about 720K. Not real significant, but it could be if a number of processes are running with Swish-e. Another option is to build libswish-e as a shared library.

UPDATE: Mon Nov 8 15:09:12 CST 2004 (karman@cray.com)

This seems done in the 2.4 release. Is that true?

Switch to Content-Types

Moseley: Dec 28, 2000

I'm wondering if it might be smart to switch from the current "Document Types" to Content-Types. Currently, Swish-e know how to parse three types of documents TXT, HTML, and XML. There's currently two new configuration directives DefaultContents and IndexContents that map file extensions to one of the three types. This doesn't really work when spidering since it's the content-type that describes the document and not the file extension.

It's an issue that can wait, but I'm concerned about backward compatiblity before people start using the IndexContents and DefaultContents config directives and then we change to content-type in the future. There's probably not that many people using those, but it might be work noting in the documentation that it will change, if we agree.

The main reason to use content-type instead is for http processing where you can't depend on the file extension to determine the document type, so with http we have to use content-type to determine how to deal with the file. This is somewhat moot, as mapping can now be done with -S prog.

I'd propose that Swish-e uses a mime.types file to map from extension to content-type. You could add or override mappings in the config file:

   AddType text/plain .doc .log

   DefaultType text/html  # like DefaultContents currently

The file source "plug-in" (whatever that ends up being) would return a content-type, but if not returned then Swish-e would map the type from the file name using the mime.types file or any AddType directives.

Again, internally Swish-e only knows about text/[TXT|HTML|XML], so there should be a way to map other types, otherwise Swish-e might ignore the file. We could continue to use the three type names or switch completely to content-types.

For example, if we continued to use [TXT|HTML|XML]

    MapType TXT  text/directory text/logfile
    MapType HTML text/html

Or maybe just extend the current directives

    IndexContents HTML .htm .html text/html

Where the content-type would have precedence over the file extensions.

This would tell Swish-e that those types are handled by those internal handlers.

Then as I've mentioned before, you might specify filters as such

   FilterDocument application/msword /path/to/word-to-text

And word-to-text would convert to text and return one of the three content-types that Swish-e knows how to parse, or a different content type if were to chain filters.

Enhanced the PropertyNames directive

Moseley: Updated Jan 13, 2001

If the PropertyNames directive was enhanced to be able to limit the number of characters stored, optionally extract text from HTML, and was able to define what type of docs (text, XML, HTML) it applied to, then the existing PropertyNames feature would work like the new StoreDescription feature but be useful for more than just one use.

I'm not clear how to enhance the syntax of Properties and/or Metanames, but here's some ideas. Rainer suggested that an xml-type of format might be best and commonly understood. That's a good idea. Below are some older ideas that I had. But you will get the idea...

The metaname structure could have flags for properties:

    1 - limiting to a length
    2 - stripping HTML
    3 - encoding HTML entities on output

Oct 9, 2001 - The code is now in Swish-e to limit a string property to a length. The stripping of HTML is an issue for discussion. And encoding entities on output should be a result_outpu.c issue.

UPDATE: Mon Nov 8 15:13:26 CST 2004 (karman@cray.com)

Is this fully supported in 2.4?

Apache/XML style configuration

This would be to allow some directives to be set per directory, or perl file extenstion (or content-type).

Document Info

$Id: SWISH-3.0.pod 1613 2005-02-02 22:53:39Z whmoseley $

.