kio-locate something for KDE ?

[David Faure]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 16 December 2002 15:10, Josef Weidendorfer wrote:
> Wouldn't it be better to support event notification in the KIO interface?
> * KDirWatch is only working with the "file:" protocol AFAIK.
> * The SAMBA slaves don't allow any automatic update because of this.
How could it? Does SMB forward "new file / deleted file etc." notifications?

> * "locate:" could use KDirWatch in its KIO slave.
> * I made a plan-KIO a year ago - worked perfectly with korganizer, using 
> VCalender format (you know this old MOTIF-based plan? it has a very easy to 
> use PIM server). Unfortunately KIO didn't support calendar event updates.
> * Putting KDirWatch into the file-KIO would be a lot cleaner.

I thought about this a bit more, and maybe something easier than events
from "otherwise idle" slaves (which is a bit against the kio desing), would be
a WatchJob.
That job would tell the slave "please monitor this or those directories",
and it would never end. The slave would answer with listEntries() for
new or modified entries, and either a new method or a special UDS_ENTRY
value for deleted entries, whenever this happens.
This is almost like the above except that it's the application which decides
it wants to hear about those "events", and it doesn't require much extension
to the KIO layer.

> Possible problems:
> * KIO slaves are simply killed by pressing Escape. Event notification jobs 
> (that is in fact "listDir") becomes a potentially never-ending job. Thus the 
> "Stop" is on when listing a directory. Pressing Escape stops 
> auto-notification. Is this the right way?

This is why it shouldn't be the listDir job that does the watching, but a new
kind of job (which would never end). If listDir never ends, many things will
be broken (completed() signals etc.). If it's a new job, for that purpose 
especially, then it should be ok (and since the slave is running a job, it 
won't be killed by the scheduler).

> * directory-tree listings: Either listDir must be extended to allow multiple 
> directories to be listed (and thus watched), and a running job must be 
> allowed to be "extended" (adding a further directory), 
I don't like that, better keep it simple (ListJob does the recursivity already)

> or more simply, start multiple jobs for each directory.
With WatchJob, it could simply be allowed to pass multiple paths to it,
if we can figure out where the new/deleted/modified items belong...

> * As there will be many a lot of "watching" KIO-slaves, it makes sense to 
> allow for one KIO-slave to do more than one jobs at once? E.g. allow many 
> "listDir" jobs to be done by one KIO-slave. But IOSlave Killing on pressing 
> Escape has to be changed.
Not a problem anymore, if we separate watching from listing.

> How is this done with HTTP?
It isn't. The auto-refresh thing is done by the client. The real server push is
the multipart data, handled by KMultiPart.

PS: for local files, I think we should keep things as they are (the KDirWatch/KDirLister
coupling). No need to start so many additional processes in the local case.

- -- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Klarälvdalens Datakonsult AB, Platform-independent software solutions
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice-1.2.1 is available - http://download.kde.org/stable/koffice-1.2.1/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+EYQh72KcVAmwbhARAmR6AKCIk96PskDasTn+8QZVWYjZp8QlAwCfVxOj
ulQMWfqUz6GqxF9l5xpZbNM=
=nRjr
-----END PGP SIGNATURE-----