[Nepomuk] Nepomuk Core - Questions & Patches

[Vishesh Handa]

On Sun, May 23, 2010 at 8:20 PM, Sebastian Trüg <trueg at kde.org> wrote:

> On 05/23/2010 04:23 PM, Vishesh Handa wrote:
> >     > One way of solving both the problems is to derive ResourceData from
> >     > QObject. And then call deleteLater() instead of "delete this".
> (Patch
> >     > attached)
> >
> >     oh, no, please don't. Totally useless overhead. It is much simpler to
> >     make the mutex recursive.
> >
> >
> > Well then we need a better way of solving the "delete this" problem.
> > When you say moving "it" into Resource, do you mean determineUri() or
> > replaceWith() ?
>
> I mean all calls of determineUri().
> Example:
> ResourceData::removeProperty calls determineUri. Instead determineUri
> should be called in Resource::removeProperty.
>

I'm sorry. I don't understand. Isn't it the same thing? If A calls B or B is
called inside A?


> The only problem here is load. But I recently thought that it could be
> merged into determineUri (or the other way around). After all most
> resources do not have more than - say - 20 properties. That is quickly
> loaded and would avoid performing yet another query. What I mean is that
> in determineUri
>
> select distinct ?r ?o where {
> { ?r nie:url <uri> . }
> UNION { <uri> ?p ?o . } } LIMIT 1
>
> could become something like
>
> select distinct ?r ?pp ?oo where {
> { ?r nie:url <uri> .
> ?r ?pp ?oo . FILTER(?r!=<uri> . }
> UNION { <uri> ?p ?o . <uri> ?pp ?oo . }
>
> to determine the URI AND load all properties at the same time.
> Just an idea I had when I thought about ways to spped it all up...
>

Seems logical. But then you call determineUri everywhere? I guess we could
make it determineAndLoad(). :-)

---------------------------

I had another idea on how to get rid of the proxy mess. I was going to tell
you about it later, as its aim was to get rid of the nasty lists and
determineUri mess, but it seems as though it would solve the proxy problem
as well. (Nice side effect!)

The ResourceManagerPrivate has 2 sets of lists. I'm going to call them
INIT-LIST (m_initializedData) and the HALF-INIT list (m_uriKickoffData &
m_idKickoffData). Whenever a Resource is created by the RMP::data()
function, it checks if it is present INIT-LIST or HALF-init list, and
accordingly gives us a RD (ResourceData).

A RD can go into the HALF-INIT lists in 4 ways - (look at determineUri)
--- KickOffId
------- nepomuk://res/ stored as a string
------- nao:identifier

--- KickOffUri
-------- nie:url
-------- nepomuk://res/

*Proposal :*
Remove the KickOffId completely. And make KickOffUri contain the
nao:identifier as well. When determineUri is being called, say m_kickOffUri
is the nepomuk resource uri, it should add itself to the INIT-LIST and it
should add all other ways of getting Initialized to the HALF-INIT list (
nao:identifier and nie:url ) This way RMP:data() will always returns the
correct RD* and a proxy wouldn't be required.

determineUri would be a lot simpler -

if( m_kickOffUri.isValid() ) {
      // check for nepomuk://res/
      // check for nie:url and the filex crap which I don't understand
} else {
     // check for nao:identifier
}

An additional thing we could do is to make removeProperty() removing the
corresponding RD from the HALF-INIT list if the property being removed is
nao:identifier or nie::url. (addProperty should check for the same)/

I hope I've been clear enough.

- Vishesh Handa


> Cheers,
> Sebastian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100523/d7a403c6/attachment.htm