creating a content system

[Roberto Cappuccio]

Alle 10:37, mercoledì 10 agosto 2005, hai scritto:
> On Wednesday 10 August 2005 10:05, Roberto Cappuccio wrote:
> > > - it searches hidden folders by default
> >
> > this can be easily made customizable/configurable (we have a KCM
> > module for that)
>
> Please have mercy and don't add GUI configure options for things like
> that. It should not index hidden folder/files at all.
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.

> > it works on every media you can mount. we would like to extend it to
> > NFS and other protocols as well
>
> 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?

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

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

>
> > >  - it relies on a lot of helper apps; i wonder at the overhead of
> > > that
> >
> > when I first started development, I begun importing code from other
> > projects like xpdf and antiword in our source tree. The bad things of
> > this approach are not immediately evident, but can be expressed as
> > follows: 1. you have to create a branch for every helper you decide
> > to import, in order to have the possibility to adapt the code to
> > Kat's needs. Every time the original code changes, you will have to
> > port the changes to your branch. 2. a lot of helpers are written in
> > languages different from C++, making the management of them much more
> > complicated
> >
> > I'm really interested in hearing your proposals for this problem.
>
> 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?

>
> > Aaron, now that you are near to Trolltech, could you please ask them
> > to speed up the development of QtSQL? Even the version which is
> > shipped with Qt4 sucks. I would really e glad to use that library
> > because then we could use whatever DBMS we want to use (PostgreSQL
> > and MySQL only to name a few).
>
> It's about 100 miles per hour. Depends whether there's wind or not.
> Phases of the moon also affect the speed of development.
> AKA don't ever expect a reasonable answer to a stupid question. If you
> have something that is an actually a question (where "it sucks, 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?
At the actual stage of development, using QtSQL you can read and write only 
simple-typed records, and also UTF-8 is not supported.
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? Is this question reasonable enough?

>
> Zack

Bye

Roberto