<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="http://git.reviewboard.kde.org/r/101522/">http://git.reviewboard.kde.org/r/101522/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On June 7th, 2011, 5:44 p.m., <b>Sebastian Trueg</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Before I look at this in detail I wanted to propose one thing: How about we expose the ClassAndPropertyTree from the storage service via DBus. Then clients can easily check ranges, domains, and so forth without the need to build any internal tree.
Then maybe at some point we might even port Nepomuk::Types to use that API which would also mean a performance increase.</pre>
 </blockquote>




 <p>On June 8th, 2011, 2:10 p.m., <b>Vishesh Handa</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I agree. It doesn&#39;t make sense to for each application to maintain their own cache, which wouldn&#39;t get updated if the ontologies are changed. But I&#39;m not so sure about dbus. I&#39;d like to do some simple tests to determine how long a round trip takes.

What do you think about using something like KSharedDataCache?</pre>
 </blockquote>





 <p>On June 8th, 2011, 2:13 p.m., <b>Sebastian Trueg</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Actually I have been thinking about that from the very start. always wanted to do that. But IMHO we should provide both: DBus API for scripts and such and the fast shared mem solution for KDE apps.</pre>
 </blockquote>





 <p>On June 8th, 2011, 2:23 p.m., <b>Vishesh Handa</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">AFAIK no one is writing scripts which use Nepomuk right now. So I care more about the shared memory solution. 

Either way, adding a dbus api is a simple task.</pre>
 </blockquote>








</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">It is agreed then. :)</pre>
<br />








<p>- Sebastian</p>


<br />
<p>On June 6th, 2011, 10:50 a.m., Vishesh Handa wrote:</p>






<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for Nepomuk and Sebastian Trueg.</div>
<div>By Vishesh Handa.</div>


<p style="color: grey;"><i>Updated June 6, 2011, 10:50 a.m.</i></p>




<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Nepomuk::Types classes are very expensive as they load all the type properties in one go. While this was acceptable when the WriterData was initialized only once, with the new Strigi Service architecture, the WriterData is initialized each time a file in indexed. It doesn&#39;t make any sense to load all the properties each time. 

Specially since we only use the range() and literalRangeType() of Nepomuk::Types::Property </pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Compared previous and current indexed data for an mp3 file.</pre>
  </td>
 </tr>
</table>




<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>nepomuk/services/strigi/indexer/nepomukindexwriter.cpp <span style="color: grey">(71d2e54)</span></li>

</ul>

<p><a href="http://git.reviewboard.kde.org/r/101522/diff/" style="margin-left: 3em;">View Diff</a></p>




  </td>
 </tr>
</table>








  </div>
 </body>
</html>