creating a content system

[Roberto Cappuccio]

Alle 12:03, mercoledì 10 agosto 2005, hai scritto:
> 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.
Your kat database resides in your home folder anyway, so you will be the only 
one having sufficient access rights to it. Or you could simply disable 
indexation of hidden folders.

> > > 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.
Ok, that's reasonable. We could provide a way to access remote Kat 
repositories.

> > > 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).
What about external hard disks and other portable devices one could simply 
move from home to office, for example?
Should I copy all 250 Gb of my external hard disk to my home folder every time 
I want to index it just because my policy is to have everything in my home 
folder?
And, again, what about CDs, DVDs and the like? Should I copy them all in my 
home folder?

> > > 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)
Removable hard disk.

> Most importantly to find what? Header files? Raw contents of man
> pages? .la files? .desktop files?
Documents I need to use in different locations.

>
> > > 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. 
OK, Scott, you have got another fan :-D
Personally, I will never use such a feature. What I use, and I use it heavily, 
is Google Desktop Search.
If I get a DVD with 4.2 Gb od PDFs, I will get for them all the same answer, 
usign contextual search: "this document, as well as other 15.000, was inside 
that DVD"... very useful.

> 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.
Oh yes? Make a little experiment, please. Create one or two PDFs in a folder, 
one of them containing the word "hello". Open kfind and try to find the file 
which contains the word "hello".
No work 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).
Ok, the library supports all of those library, I know. But what is the utility 
of it if the drivers you supply (I speak mainly for QSQLITE3) do not support 
it?

>
> > 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.
Again, the library supports it. Some drivers (almost all) do not.

> 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.
So, if I remember well, last time I tried it (I downloaded and compiled the 
code of the final release of Qt4) only Microsoft SQL and Oracle drivers 
supported almost all features (not all of them anyway).
SQLite3, PostgreSQL and MySQL supported one or two of them at a time.
Maybe the situation has changed in the meanwhile? 
Could you please confirm that, for example, the QSQLITE3 driver supports all 
features mentioned above?
I really need good drivers for PostgreSQL and MySQL, other than SQLite3, of 
course. All KDE community needs them, not only Kat.

> > 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.
:-D

> > 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

Roberto