[Nepomuk] Fwd: Patches and issues with search/strigi

[Peter Penz]

Hello Daniel,

sorry for the late reply and thanks for the patches!

On Friday, 1. January 2010 17:35:53 Daniel Winter wrote:
 [...]
> dolphinsearch.patch: (against dolphin)
>
> Two isses fixed by this patch:
> - Date - Today was an "is equal query", but it works on times. So it
> gives no results most of the time. Change it to is equal or greater.
> In theory it will also hit files from the future. Put they shouldn't
> exist anyway.
>
> (There are more similar but harder to fix issues for example search
> for files eqal or less 1.1.2010 will not find files from today.
> (because it compares it with the start of the current day. And so
> files from today are not equal or less that..)
>
> - Searches in NIE::lastModified instead of NAO::lastModified with the
> patch.  I think that is what the user cares about. (The modifed date
> of the file, not the information when tagged it or something.) This
> way one actually get the expected results. (or do you really think NAO
> is correct? )
>
> Can i commit those?

Please commit the Dolphin patch, it looks good. Regarding the other patches I 
hope that Sebastian or someone else can comment...

Best regards,
Peter

>
>
> There are some more issues, which I don't have the time or knowledge
> (atm) to fix:
>
>
> - strigiservice  monitoring:
>
> It doesn't catch changes in files. It recurses over the directorys for
> changed modifed time. The problem is: The directory modified time only
> gets changed when one renames, creates or deletes file in the
> directory. Not when a file just gets changed (like the modification
> date or content). I think catching this is important.
>
> There is no obvious solution to this. Inotify would be one. But there
> is the limit on handles. I think it is the right way anway. Most users
> will not add all directories to strigi/nepomuk and therefore never hit
> the limit. Nepomuk could count the number of directories the user has
> in his indexed dirs and check if there are enough inotify handles set
> in the system. (It should leave at least 30% of them to other
> applications) If there are enough (respecting the reserver for the
> rest) it should use them.
>
> The kde filewatch thing (the one the filewatch service uses) could be
> a fallback for systems with not enough or no inotify at all.
>
> - Search result caching/auto updating:
>
> There seam to be some regression there. You have to wait a lot of time
> or restart Nepomuk to find newly tagged files for example.
>
> 1. Search for files tagged with "x"
> 2. Tag another file with "x"
> 3. search for files tagged with "x"
>
> The file will not show up for a quite some time. (or restart of
> Nepomuk) It used to get updated in realtime in 4.3.
>
> -- Nepomuk IO-Slave  URL/Forwaring/file handling
>
> Not sure what exactly is happening or if it is intented to work this
> way. From my point of view (as a user of it) it is a regression.
>
> Opening search results from Dolphin opens the nepomuk://  uri or
> something. You get some really weird filename shown in the
> Applications. One could live with that. The problem is: Non KDE
> Applications are getting some tmp file. It doesn't look like writing
> to this file is possible. (KIO asks if I want to upload the file, and
> if I say yes it tells me that writing to Nepomuk is not supported).
>
> I believe related to this is the really slow preview of files (for
> example Images) in Dolphin when there are a lot. Every single preview
> results in a request to Nepomuk wich opens and closes a connection to
> soprano on every request (this seems to be a general issue?)
>
> Also somehow the caching of Nepomuk::ResourceManager doesn't really
> work? It opens a new Soprano connection to virtuoso on every single
> mouse over on the results of a search in Dolphin.
>
> -- Dolphin search (or the search io slave) should have a (default)
> limit of results.
>
>
> I am just reporting these. I most likely will not find the time to
> look further into fixing them. I will try a patch or bring more
> details if needed though.
>
> Daniel