---

Last-Modified: $Date: 2002/01/30 23:28:09 $ 
Version: $Id: SEARCH_FRAMEWORK,v 1.6 2002/01/30 23:28:09 burton Exp $
Author: Kevin A. Burton ( burton@apache.org | burton@openprivacy.org )

Commentary:

---

TODO:

- Should we support the concept of a SearchQuery that we can then give to a
  specific provider which would allow them to perform any local mapping?  I
  think so.

    - Maybe in the future.  Right now we can execute search queries right away
      through torque.  Of course this is very short sighted thinking.

    - of course this way we coudl support generic search properties such as
      maximum results, query string, etc.

    - at the very minimum we should have the ability to set search options.
     
- We need to fully document the search XML result format.  This needs to reside
  in a dedicated file on the site.

Design:
    
- The results format XSLT should have the ability to page through a result set.

- org.openprivacy.reptile.search package holds all related classes WRT search.

    - org.openprivacy.reptile.search.actions holds all search related actions.

        - org.openprivacy.reptile.search.actions.Search is an action which can
          invoke a search and return a representation of the search.  NOTE: this
          way we can probably support search providers.

          -it accepts the following HTTP params (usually done with POST)

                - reptile.search.order (channel | title | date_found) )

                - reptile.search.fields (comma separated list of fields to match)

                     - title, description, location, etc.

                - reptile.search.maxcount (maximum number of items to return 100, 200, 300, etc)

                - reptile.search.provider (the classname of the provider to use to execute the query.)

    - package structure should include:

        org.openprivacy.reptile.search.providers
            (executes searches and fills in the results of the search as a cursor)

        org.openprivacy.reptile.search.providers.SearchProvider 
                 (interface that must be met by search providers)

        org.openprivacy.reptile.search.providers.ArticleSearchProvider

             - provides a search provider which can search articles in the DB.
        
        org.openprivacy.reptile.search.providers.ChannelSearchProvider

            - provides a search provider that can search channels in the DB.

    - We need to have the concept of an abstracted cursor.  Specifically because
      we NEED to be able to page through result sets in an abstract manner.

        - everything here should be in an org.openprivacy.reptile.search.cursor
          package.
      
        - The CursorEntry class should be held by a single Cursor which can
          hold multiple CursorEntries.

            - This should be both an interface an implementation.  We need to
              have Articles, Channels, etc wraped so that we can use them as
              CursorEntries.

            - Of course maybe we don't need CursorEntries at all... maybe we
              could use some type of serializer.

            - I don't think we should do this.  We should just output XML from
              the range.  (yes this means we will have to write more code but we
              will be able to avoid garbage collection)

            - of course maybe we could have some type of visitor pattern where
              we could put the code into a visitor and then serialize it again
              and again sharing the code.  We would only have to create one
              instance of the visitor and then serialize it multiple times.

            - No.. I just need to find a pattern from Design Patterns and
              implement this!!
              
        - A Cursor can serialize itself as XML for the given range/page and
          provide counts for the number of pages, etc.

        - Supports disconnected operation so that JXTA results can pour in while
          the server is still running

        - every cursor should be held within a singleton and garbage collected
          after X amount of time.  This GC should be done by CursorGCThread.

        - needs to have a fixed URL probably based on currentTimeMillis

        - CursorManager.getInstance().getCursor() should throw an exception if
          the given cursor is not available.