Hey Sebastian<br><br><div class="gmail_quote">On Mon, May 24, 2010 at 1:45 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;">
Hi Vishesh,<br>
<br>
I don't really see how this can work. After all the same resource could<br>
still be accessed in two different ways. For example we have this resource:<br>
<br>
nepomuk:/res/foobar<br>
nao:identifier "foobar" .<br>
<br>
Now the code:<br>
<br>
Resource r1( QUrl("nepomuk:/res/foobar" ) );<br>
Resource r2( "foobar" );<br>
<br>
At this point determineUri has not been called for any resource yet and<br>
as far as RM is concerned those are different resources with 2 different<br>
RDs.<br></blockquote><div><br>You're right. I forgot that determineUri has to be called at least once. :-( I think we should add a test for this. <br><br>Hmm, so we still need some kind of proxies. I guess it's time to combine determineUri() and load().<br>
<br>- Vishesh Handa<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Be aware though that I did not look at your patch in detail yet. I will<br>
do that later. So I might have missed something. :)<br>
<br>
Cheers,<br>
<font color="#888888">Sebastian<br>
</font><div class="im"><br>
On 05/23/2010 05:54 PM, Vishesh Handa wrote:<br>
><br>
> On Sun, May 23, 2010 at 8:20 PM, Sebastian Trüg <<a href="mailto:trueg@kde.org">trueg@kde.org</a><br>
</div><div><div></div><div class="h5">> <mailto:<a href="mailto:trueg@kde.org">trueg@kde.org</a>>> wrote:<br>
><br>
> On 05/23/2010 04:23 PM, Vishesh Handa wrote:<br>
> > > One way of solving both the problems is to derive<br>
> ResourceData from<br>
> > > QObject. And then call deleteLater() instead of "delete<br>
> this". (Patch<br>
> > > attached)<br>
> ><br>
> > oh, no, please don't. Totally useless overhead. It is much<br>
> simpler to<br>
> > make the mutex recursive.<br>
> ><br>
> ><br>
> > Well then we need a better way of solving the "delete this" problem.<br>
> > When you say moving "it" into Resource, do you mean determineUri() or<br>
> > replaceWith() ?<br>
><br>
> I mean all calls of determineUri().<br>
> Example:<br>
> ResourceData::removeProperty calls determineUri. Instead determineUri<br>
> should be called in Resource::removeProperty.<br>
><br>
><br>
> I'm sorry. I don't understand. Isn't it the same thing? If A calls B or<br>
> B is called inside A?<br>
><br>
><br>
> The only problem here is load. But I recently thought that it could be<br>
> merged into determineUri (or the other way around). After all most<br>
> resources do not have more than - say - 20 properties. That is quickly<br>
> loaded and would avoid performing yet another query. What I mean is that<br>
> in determineUri<br>
><br>
> select distinct ?r ?o where {<br>
> { ?r nie:url <uri> . }<br>
> UNION { <uri> ?p ?o . } } LIMIT 1<br>
><br>
> could become something like<br>
><br>
> select distinct ?r ?pp ?oo where {<br>
> { ?r nie:url <uri> .<br>
> ?r ?pp ?oo . FILTER(?r!=<uri> . }<br>
> UNION { <uri> ?p ?o . <uri> ?pp ?oo . }<br>
><br>
> to determine the URI AND load all properties at the same time.<br>
> Just an idea I had when I thought about ways to spped it all up...<br>
><br>
><br>
> Seems logical. But then you call determineUri everywhere? I guess we<br>
> could make it determineAndLoad(). :-)<br>
><br>
> ---------------------------<br>
><br>
> I had another idea on how to get rid of the proxy mess. I was going to<br>
> tell you about it later, as its aim was to get rid of the nasty lists<br>
> and determineUri mess, but it seems as though it would solve the proxy<br>
> problem as well. (Nice side effect!)<br>
><br>
> The ResourceManagerPrivate has 2 sets of lists. I'm going to call them<br>
> INIT-LIST (m_initializedData) and the HALF-INIT list (m_uriKickoffData &<br>
> m_idKickoffData). Whenever a Resource is created by the RMP::data()<br>
> function, it checks if it is present INIT-LIST or HALF-init list, and<br>
> accordingly gives us a RD (ResourceData).<br>
><br>
> A RD can go into the HALF-INIT lists in 4 ways - (look at determineUri)<br>
> --- KickOffId<br>
> ------- nepomuk://res/ stored as a string<br>
> ------- nao:identifier<br>
><br>
> --- KickOffUri<br>
> -------- nie:url<br>
> -------- nepomuk://res/<br>
><br>
> *Proposal :*<br>
> Remove the KickOffId completely. And make KickOffUri contain the<br>
> nao:identifier as well. When determineUri is being called, say<br>
> m_kickOffUri is the nepomuk resource uri, it should add itself to the<br>
> INIT-LIST and it should add all other ways of getting Initialized to the<br>
> HALF-INIT list ( nao:identifier and nie:url ) This way RMP:data() will<br>
> always returns the correct RD* and a proxy wouldn't be required.<br>
><br>
> determineUri would be a lot simpler -<br>
><br>
> if( m_kickOffUri.isValid() ) {<br>
> // check for nepomuk://res/<br>
> // check for nie:url and the filex crap which I don't understand<br>
> } else {<br>
> // check for nao:identifier<br>
> }<br>
><br>
> An additional thing we could do is to make removeProperty() removing the<br>
> corresponding RD from the HALF-INIT list if the property being removed<br>
> is nao:identifier or nie::url. (addProperty should check for the same)/<br>
><br>
> I hope I've been clear enough.<br>
><br>
> - Vishesh Handa<br>
><br>
><br>
> Cheers,<br>
> Sebastian<br>
><br>
><br>
</div></div></blockquote></div><br>