Proposed changes for Swish-e 3.0
[ TOC ]
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 ;).
[ TOC ]
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.
[ TOC ]
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.
[ TOC ]
Swish Server
Somone needs to write a threaded Swish-e server. Or maybe just a pre-forking server in perl, to see how it works...
[ TOC ]
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.
[ TOC ]
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 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.
[ TOC ]
Apache/XML style configuration
This would be to allow some directives to be set per directory, or perl file extenstion (or content-type).
[ TOC ]
Document Info
$Id: SWISH-3.0.pod,v 1.6 2002/04/15 02:34:43 whmoseley Exp $
. [ TOC ]