Some really simple stuff:

An indexer/fast search application:

(lo que esta entre corchetes, es funcionalidad que se añadirá después)

indexa archivos.  la primera vez indexa todo, [ejecutando la indexación con baja prioridad].  [De ahi, en cada directorio que encuentre, sembrará kdirwatchers para verificar si se crean archivos o carpetas]

tablas:
- archivos: ID, archivo
- propiedades: ID archivo, source type (file, filesystem attribute), propertytype ID (ver abajo), valor (varios tipos, minimo string, int, datetime)

(usaremos sqlite)   CANCELADO

we need a way to classify properties:
tabla propertytypes: ID, nombre de la propiedad, tipo de datos (char de 1, si es date, sera d, strings c, integers i)
conforme el indexer vaya descubriendo las diferentes clases de propiedades, debe ir ingresándolas a esta tabla

usar python y pykde para el kfilemetainfo stuff.


search part:

una interfaz de usuario parecida a evolution, donde salga una ventana principal:

-----------------------------------------------------------------------
| search for: [ propertytype |V| ] [ control apropiado para el tipo ] |
-----------------------------------------------------------------------
|                                                                     |
| Result list apropiado en formato Konqueror                          |
|                                                                     |
|                                                                     |
|                                                                     |
|                                                                     |
|                                                                     |
-----------------------------------------------------------------------

en el dropdown de propertytype tiene que aparecer advanced... también,
para bring out un formulario parecido al de la búsqueda de GNOME.



class names que se me ocurren:

KSearchWindow (the search window)
Index (the database)
FilesystemCrawler (the file system crawler, crawls the filesystem entirely, needs to take a short break between files, should emit a signal each time a file is available for indexing, and terminate once it's done)
[FilesystemMonitor (the filesystem monitor, should emit a signal each time a file is available for indexing)]






The Metadata Daemon:
- indexes files and is in charge of replying to search queries.  Informs to user applications which propertytypes exist.  Receives a query in SQL form (only the WHERE part, not need the select * from) (should rip everything after a non-quoted semicolon, of course).  It spits out a file list, separated by NULLs, like find -print0.  It also receives a query with a file and replies with its properties, in a form yet to be standardized (XML?).  It should be prepared to have clients abort at any time of the query/reply process.

[need to build a find(2) compatible command]





Search details:
* strings:
- exact matches (string_exact)
- case-insensitive exact matches (string_icase)
- case-insensitive globbing matches (string_glob) (to fill in for substring matches, the app should wrap these in * *)
* text:
- case-insensitive globbing matches (text_glob)
- case-insensitive word matches (text_word_all,text_word_any,text_word_near)
* integer/float
- exact matches (numeric_exact)
- greater than/less than matches (numeric_lessthan, numeric_greaterthan)
* date
- exact matches (date_exact)
- greater than/less than matches (date_before, date_after)
* path
- self-and-contained entries (path_at_or_below)

when requesting an unsupported type of index, that is an error and the app should return so

the basic search expression goes like this:
{ key : 'artist' , type: 'string_icase' , value: 'something' }
they can be combined, with operator expressions like this:
{ "expressions" : [ expr1, expr2 ] , operator: "or" }
and that can be combined even further with the same approach


key path_at_or_below 'path'
key string_exact 'something'
key string_icase 'something'
key string_glob '*something*'   # enforce at least one globbing char
key text_glob '*something*'
key text_word_all 'something somethingelse'
key text_word_any 'something somethingelse'
key text_word_near 'something somethingelse'
key numeric_exact 
key numeric_greaterthan 3
key numeric_lessthan 3
... you get the idea

# need to enforce types
those can be strung together with ands and ors

(key greaterthan 3)




as I see them, AND searches can be combined into one query, while OR searches NEED to be executed separately.  This is the basic constraint.  When two or more OR searches are conducted, the results need to be collated and uniqueized.

this service will have several interfaces:
- socket-based
[- tcp/ip based]

both will expose an HTTP/XML-RPC interface.  Socket-based connections will use the connecting user's user privileges, while TCP/IP connections will require HTTP Basic authentication.

The process is as follows:
- the client connects to the server and requests via GET or POST the /rpc2/ interface.
- the client executes the XML-RPC method call
- the server processes the method call, and returns the return values to the client
- if appropriate and the client requests it (via an HTTP header), the server keeps the connection open to provide for additional data (clients which require this should process the response asynchronously, and close the connection when they deem appropriate)

on errors, the server always closes the connection after responding with the error.

Interface methods:
- search: receives a query struct (q), replies with a file list (p)
- getMetadata: receives a file name, returns the stored object's metadata (r)


query struct q:




file list p:
	this is a simple list [ "/home...", "/home..." ]