[Nepomuk] Nepomuk Core - Questions & Patches

[Vishesh Handa]

On Mon, May 31, 2010 at 5:47 PM, Sebastian Trüg <trueg at kde.org> wrote:

> On 05/31/2010 01:44 PM, Vishesh Handa wrote:
> > Resources are identified by one of these 3 ways -
> > 1. nao:identifier
> > 2. nie:url (includes the whole filex:/ part)
> > 3. nepomuk:/res/
> >
> > m_kickOffId uses 1, 2 (minus the filex:/) & 3. And m_kickOffUri uses 2 &
> > 3. I say, we scrap the m_kickOffId, and store the nao:identifier in the
> > m_kickOffUri ( perhaps name it to something else? )
> >
> > The determineUri code would become a lot simpler -
> >
> > if( m_kickOffUri.isValid() ) {
> >    // Either 2 or 3
> > }
> > else {
> >    // nao:identifier
> > }
> >
> > The would even clear one of the odd cases where someone tries to
> > initialize a Resource by providing its nepomuk:/res/ uri as a QString
> > instead a QUrl.
>
> So you want to store a string in a KUrl then? Well, that could work indeed.
>

Yup. Or if you really want we could do the opposite and store everything as
strings.


>
>
> >     > 2. Convert the ResourceData m_kickOffUri into a list AND make sure
> >     that
> >     > while determining one URI it adds all other cases to the lists as
> >     well.
> >     >
> >     > Number 1 is more of a convenience, but *2* is really important.
> You've
> >     > done half the job ( I thought we'll take care of it in another
> patch )
> >     >
> >     > Now, about the comments in determineFinalResourceData(). The flaw
> with
> >     > our, not so little, proxy removal plan was that if -
> >     > Resource r1("foo");
> >     > r1.determineUri()
> >     >
> >     > Resource r2( foo's nie:url );
> >     > r2.determineUri() // The proxy thing would be activated ( could be
> >     > avoided via 2 )
> >     >
> >     > Resource r3( foo's nie:url );
> >     > r3.determineUri() // The proxy thing is AGAIN activated as the
> nie:url
> >     > wasn't added to the list.
> >     >
> >     > With your patch you seem to have fixed the problem. But I would
> have
> >     > preferred the more concrete solution via 2.
> >
> >     Agreed.
> >
> > How about converting them into hash tables instead of lists? That way we
> > could easily check if addProperty() or removeProperty() updates any of
> > the identifying properties in m_kickOddUri. We could then even
> > potentially stop clearing up the cache after ever metadata move
> > operation.
>
> What would the hash contain?
>
>
Uhh. What I meant was that we store them in a set instead of a list. It's a
rather trivial thing.

I guess I'll start modifying the patch.

- Vishesh Handa



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