From kde-core-devel Tue Dec 31 11:48:49 2002 From: David Faure Date: Tue, 31 Dec 2002 11:48:49 +0000 To: kde-core-devel Subject: Re: kio-locate something for KDE ? X-MARC-Message: https://marc.info/?l=kde-core-devel&m=104135832813811 =2D----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= =20 > VCalender format (you know this old MOTIF-based plan? it has a very easy = to=20 > 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 job= s=20 > (that is in fact "listDir") becomes a potentially never-ending job. Thus = the=20 > "Stop" is on when listing a directory. Pressing Escape stops=20 > auto-notification. Is this the right way? This is why it shouldn't be the listDir job that does the watching, but a n= ew 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=20 especially, then it should be ok (and since the slave is running a job, it= =20 won't be killed by the scheduler). > * directory-tree listings: Either listDir must be extended to allow multi= ple=20 > directories to be listed (and thus watched), and a running job must be=20 > allowed to be "extended" (adding a further directory),=20 I don't like that, better keep it simple (ListJob does the recursivity alre= ady) > 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= =20 > allow for one KIO-slave to do more than one jobs at once? E.g. allow many= =20 > "listDir" jobs to be done by one KIO-slave. But IOSlave Killing on pressi= ng=20 > 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 pus= h is the multipart data, handled by KMultiPart. PS: for local files, I think we should keep things as they are (the KDirWat= ch/KDirLister coupling). No need to start so many additional processes in the local case. =2D --=20 David Faure -- faure@kde.org, dfaure@klaralvdalens-datakonsult.se Klar=E4lvdalens 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/ =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+EYQh72KcVAmwbhARAmR6AKCIk96PskDasTn+8QZVWYjZp8QlAwCfVxOj ulQMWfqUz6GqxF9l5xpZbNM=3D =3DnRjr =2D----END PGP SIGNATURE-----