<table><tr><td style="">vhanda added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D4911" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>I'm not the maintainer of Baloo any more, so I don't want to give it a clear Yes / No.</p>

<p>This patch is going to be a big CPU hog. For files this will barely have an impact, but for folders of a large enough size, it's going to result in tons of dbus signals, and more importantly, tons of database lookups and full path constructions. It really will add up. In an earlier version of Baloo, we used to store the full file paths, which meant when a folder moved, every sub-file/folder's URL had to be updated. That was a huge CPU burner. This patch isn't that bad, but it's half way there.</p>

<p>I cannot see what advantage these signals add, apart from possibly making Baloo more introspect-able. If it's to build applications on top of Baloo, I would recommend against it. The kernel provides file system monitoring APIs which should be used instead.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R293 Baloo</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D4911" rel="noreferrer">https://phabricator.kde.org/D4911</a></div></div><br /><div><strong>To: </strong>mgallien, vhanda<br /><strong>Cc: </strong>apol, Frameworks<br /></div>