<br><br><div class="gmail_quote">On Mon, May 31, 2010 at 5:47 PM, Sebastian Trüg <span dir="ltr"><<a href="mailto:trueg@kde.org">trueg@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 05/31/2010 01:44 PM, Vishesh Handa wrote:<br>
> Resources are identified by one of these 3 ways -<br>
> 1. nao:identifier<br>
> 2. nie:url (includes the whole filex:/ part)<br>
> 3. nepomuk:/res/<br>
><br>
> m_kickOffId uses 1, 2 (minus the filex:/) & 3. And m_kickOffUri uses 2 &<br>
> 3. I say, we scrap the m_kickOffId, and store the nao:identifier in the<br>
> m_kickOffUri ( perhaps name it to something else? )<br>
><br>
> The determineUri code would become a lot simpler -<br>
><br>
> if( m_kickOffUri.isValid() ) {<br>
> // Either 2 or 3<br>
> }<br>
> else {<br>
> // nao:identifier<br>
> }<br>
><br>
> The would even clear one of the odd cases where someone tries to<br>
> initialize a Resource by providing its nepomuk:/res/ uri as a QString<br>
> instead a QUrl.<br>
<br>
</div>So you want to store a string in a KUrl then? Well, that could work indeed.<br></blockquote><div><br>Yup. Or if you really want we could do the opposite and store everything as strings.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
<br>
> > 2. Convert the ResourceData m_kickOffUri into a list AND make sure<br>
> that<br>
> > while determining one URI it adds all other cases to the lists as<br>
> well.<br>
> ><br>
> > Number 1 is more of a convenience, but *2* is really important. You've<br>
> > done half the job ( I thought we'll take care of it in another patch )<br>
> ><br>
> > Now, about the comments in determineFinalResourceData(). The flaw with<br>
> > our, not so little, proxy removal plan was that if -<br>
> > Resource r1("foo");<br>
> > r1.determineUri()<br>
> ><br>
> > Resource r2( foo's nie:url );<br>
> > r2.determineUri() // The proxy thing would be activated ( could be<br>
> > avoided via 2 )<br>
> ><br>
> > Resource r3( foo's nie:url );<br>
> > r3.determineUri() // The proxy thing is AGAIN activated as the nie:url<br>
> > wasn't added to the list.<br>
> ><br>
> > With your patch you seem to have fixed the problem. But I would have<br>
> > preferred the more concrete solution via 2.<br>
><br>
> Agreed.<br>
><br>
> How about converting them into hash tables instead of lists? That way we<br>
> could easily check if addProperty() or removeProperty() updates any of<br>
> the identifying properties in m_kickOddUri. We could then even<br>
> potentially stop clearing up the cache after ever metadata move<br>
> operation.<br>
<br>
</div>What would the hash contain?<br>
<br></blockquote><div><br>Uhh. What I meant was that we store them in a set instead of a list. It's a rather trivial thing.<br><br>I guess I'll start modifying the patch.<br><br>- Vishesh Handa <br></div><div><br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Cheers,<br>
<font color="#888888">Sebastian<br>
</font></blockquote></div><br>