creating a content system

[Aaron J. Seigo]

On Wednesday 10 August 2005 03:11, Manuel Amador wrote:
> > I don't think you ever want to be doing indexing on nfs shares. Ever.
> > Actually nothing outside user home directories should be indexed. Then
> > a system like the one Scott proposed for tenor where you search outside
> > using links could be utilized.
>
> oh,no... at least it should index /usr/share/doc and /usr/share/man!!!
>
> what's wrong with indexing all locally mounted file systems?  Tons of

well, besides this being nearly irrelevant for most users? things 
like /usr/share/doc/ and man/ make sense of course. and packagers could even 
distribute them pre-indexed, and these indexes could be merged into a 
system-wide database.

> 1. if your daemon is per-user you'll need a database cluster for that
> user in a hidden $HOME/.indexer directory, and a database daemon running
> for that user.  That is completely platform-dependent code (platform in
> the sense of chosen database)

to repeat what i said in another email a few minutes ago: there will be no 
per-user database engine. storage, population and retrieval are three 
separate processes in the larger game and each has its own response.

storage: system wide rdbms, can contain more than one index repository
population: simple daemon that can be run per-user or system-wide
retrieval: per user

> 2. queries you will be writing will sadly perform or work differently
> across databases, so there's not much of a point in abstracting database
> adaption, when your final choice should already be set on stone, based
> on inherent database brand properties, like query speed and whether the
> database you want does actually support what you want. 

this i'd agree with. note, however, that as you found out you can switch 
engines over time. this is an implementation detail and one that can be 
addressed during development. i'm not too overly concerned about it beyond 
ensuring that we have the base requirements covered in whatever we start with 
(network capable, multi-user, standard SQL, stored procedures...)

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/klink/attachments/20050811/f5df2e93/attachment.pgp