creating a content system

[Zack Rusin]

On Wednesday 10 August 2005 11:04, Roberto Cappuccio wrote:
> In my system the mail folder is in ~/.kde/share/apps/kmail and I
> surely want to index my mails. And there are surely other hidden
> directories around a user may want to index. What about Konversation
> logs (they are in .kde/share/apps/konversation/logs/ for instance) or
> kopete logs or... I think you should think twice before cutting off
> ALL hidden folders.

No, I really don't. I want application support for that. I don't want 
anything touching my hidden folders. I definitely wouldn't appreciate 
having conversations with hardware vendors, nda's and hardware specs 
that i'm getting in my emails indexed. I just would like to use indexer 
without having to break the law when I do so. If we can't do that then 
we can just abandon the whole concept of desktop search. Companies  
would never ever allow anything like that running.

> > I don't think you ever want to be doing indexing on nfs shares.
> > Ever.
>
> Why not??? And why not extending it to SSH and FTP as well?

Because I have a 3TB nfs share and I wouldn't want every client on the 
network indexing it. What I'd like is to have link relantionship 
between indexes and machines. So that nfs server can index its content 
itself and my desktop system somehow can query that external data.

> > Actually nothing outside user home directories should be indexed.
>
> I have a lot of research papers stored outside my home directory.
> Should I cut them off because of that? And what about CDs, DVDs and
> the like? Should I really limit Kat to my home directory?

Yes! Storing anything outside of home directory is the geekiest of the 
geeky inventions of the geek culture. "Oh, i'll create /opt/papers 
because I created fifty partitions on my system and I don't have space 
on my /home". Users don't care about indexed /usr/lib, /usr/bin and 
mostly not about /usr/include. If I'm a using my computer to do actual 
work and I'm looking for some file then "/usr/include/asm/linux.h" or 
anything from within /usr/include will never be it. 
Documentation is something else but I'd also argue that it would be a 
lot better if there was a way for khelpcenter to communicate the data 
to the system (hence why we need API that the aps could use). 

> > Then a system like the one Scott proposed for tenor where you
> > search outside using links could be utilized.
>
> And what about searching for content (fulltext) outside of my home
> directory?

Who would ever want to do that? (please don't tell me that you've got 
papers in /opt/spare_parition/papers) 
Most importantly to find what? Header files? Raw contents of man 
pages? .la files? .desktop files? 

> > Support from application themselves of course.
>
> How? Kindly asking the developers of every application to supply a
> fulltext plugin for Kat? Do you think they will even answer to your
> mail? And if they do, in how much time will you get the plugin?

That's why we need the api for. Desktop searching in itself is 
uninteresting, it's the relationship between documents that are 
interesting "oh, this file was originally an attachment that I got from 
John in an email so it relates to this and that" that's just one of the 
really interesting thing we can do with it. Otherwise we might as well 
stick with kfind and do full searches on /. Sure it will be slower but 
we already have it so no work there at all. 

> i can't use it" is _not_ a question) then I could try to answer it.
>
> OK, let's be a little bit more detailed.
> How would you consider a SQL driver (like QSQLITE3, but also the
> QtSQL drivers for PostgreSQL and MySQL) which lacks blobs, named and
> positional placeholders in queries, prepared statements, last insert
> id and a lot of other things?

Actually we support all of those features (all the way up till " a lot 
of other things" which is again a broken statemant).

> At the actual stage of development, using QtSQL you can read and
> write only simple-typed records, and also UTF-8 is not supported.

Yes it is.

The bottom line is that all those things are dependent on which database 
you use. If your database supports it then we of course do as well.

> Unfortunately we need all of these features in Kat.
> How much time will they need to implement those things in their
> drivers, given that those things are already available in the
> libraries of the DBMS cited above? 

Well, given that we support all of it I'd say: 0 seconds, which is a 
rather impressive speed if you ask me.

> Is this question reasonable  enough?

Yes, it is. And we support everything you're asking for so it's just a 
matter of you actually using it.

Zack

-- 
Gates' Law: Every 18 months, the speed of software halves.