=head1 NAME

Proposed changes for Swish-e 3.0

=head1 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 ;).


=head1 UTF-8 support

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


=head1 drop expat-based parsers, require libxml2

This might simplify the code somewhat as well.


=head1 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'?


=head1 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?

=head1 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.


=head1 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?

=head1 Apache/XML style configuration

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


=head1 Document Info

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

.