[Nepomuk] Re: SimpleResource rcgen redesign draft

Christian Mollekopf chrigi_1 at fastmail.fm
Tue Jul 26 16:46:09 CEST 2011


On Tue, 26 Jul 2011 13:37:12 +0200, Sebastian Trüg <trueg at kde.org> wrote:

> On 07/26/2011 10:06 AM, Christian Mollekopf wrote:
>> On Tue, 26 Jul 2011 09:52:20 +0200, Sebastian Trüg <trueg at kde.org>  
>> wrote:
>>
>>> On 07/25/2011 11:17 PM, Christian Mollekopf wrote:
>>>> On Mon, 25 Jul 2011 23:09:26 +0200, Christian Mollekopf
>>>> <chrigi_1 at fastmail.fm> wrote:
>>>>
>>>>> Another thing I just noticed:
>>>>> The constructor should already set the type,
>>>>> in case no properties are set.
>>>>
>>>> Hmm... I guess it was done this way to avoid setting the myriad of  
>>>> types
>>>> in the hierarchy.
>>>
>>> exactly.
>>>
>>>> Maybe add an explicit setType function instead, or add it to the
>>>> resource() function,
>>>> if you go for the copy version.
>>>
>>> Hm, is it really necessary to have a type if nothing else is set? Why
>>> does one need the resource then anyway?
>>>
>>
>> Because i.e. in the feeder I add only properties which don't actually
>> belong to the most specific type.
>> (Things like the label, NCAL:location for incidences, etc)
>>
>> Still all created items must have the right type, i.e. for queries with
>> fulltext search.
>> And btw. think of the AkonadiDataObject type, where we don't even have a
>> property to add for collections.
>
> I suppose I could add a protected constructor to all classes which would
> be used by child classes. This constructor would take a type URI as
> input. That way only the top-level type would be set.

Yep, that sound like a good idea.

Cheers
>
> Cheers,
> Sebastian
>
>> Cheers
>>
>>>>>
>>>>> On Mon, 25 Jul 2011 21:20:45 +0200, Sebastian Trüg <trueg at kde.org>
>>>>> wrote:
>>>>>
>>>>>> On 07/25/2011 07:52 PM, Christian Mollekopf wrote:
>>>>>>> On Mon, 25 Jul 2011 18:30:05 +0200, Sebastian Trüg <trueg at kde.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Now that the SimpleResource rcgen is in git master[1] some people
>>>>>>>> used
>>>>>>>> it (mostly for Akonadi feeders and the web extractor framework)  
>>>>>>>> and
>>>>>>>> found it to be a bit strange.
>>>>>>>>
>>>>>>>> This is true. Current usage is as follows:
>>>>>>>>
>>>>>>>> SimpleResource r;
>>>>>>>> NCO::PersonContact(&r).setFullname("foobar");
>>>>>>>>
>>>>>>>> The reason for this is simple: due to multi-inheritance problems I
>>>>>>>> cannot derive the generated classes from SimpleResource. Thus, we
>>>>>>>> need
>>>>>>>> wrappers.
>>>>>>>>
>>>>>>>> Now some ideas were floating around and I would like to settle on
>>>>>>>> one
>>>>>>>> better solution.
>>>>>>>>
>>>>>>>> One idea would be to have a hybrid thing where you could do this:
>>>>>>>>
>>>>>>>>   NCO::PersonContact pc;
>>>>>>>>   pc.setFullname("foobar");
>>>>>>>>   SimpleResource r = rc.resource();
>>>>>>>>
>>>>>>>> and this:
>>>>>>>>
>>>>>>>>   SimpleResource r;
>>>>>>>>   NCO::PersonContact pc(r);
>>>>>>>>   pc.setFullname("foobar");
>>>>>>>>   r = pc.resource();
>>>>>>>>
>>>>>>>> (The last line would be required since all SimpleResources would  
>>>>>>>> be
>>>>>>>> copies.)
>>>>>>>
>>>>>>> Why can't you just take the reference to r, and the last copy
>>>>>>> wouldn't
>>>>>>> be
>>>>>>> needed?
>>>>>>> Of course the accessor is still needed for the NCO::PersonContact  
>>>>>>> pc;
>>>>>>> usecase.
>>>>>>
>>>>>> I cannot use refs for security reasons. Imagine someone returns a
>>>>>> generated class from a method after putting in a ref to a local
>>>>>> SimpleRes. Anyway, SimpleRes is implicitly shared.
>>>>>>
>>>>>>>>
>>>>>>>> We could go on like so:
>>>>>>>>
>>>>>>>>   r.addProperty(...);
>>>>>>>>   pc = r;
>>>>>>>>   pc.setResource(r);
>>>>>>>>
>>>>>>>> The only disadvantage I see here might be a slight performance
>>>>>>>> overhead
>>>>>>>> due to the copying of the resources.
>>>>>>>>
>>>>>>>> Opinions?
>>>>>>>
>>>>>>> Additionally it might be nice to have an accessor to the uri of the
>>>>>>> SimpleResource directly in the wrapper,
>>>>>>> and the << operator for the graph.
>>>>>>>
>>>>>>> So we would go from this:
>>>>>>>
>>>>>>>    Nepomuk::SimpleResource iconRes;
>>>>>>>    Nepomuk::NAO::FreeDesktopIcon icon(&iconRes);
>>>>>>>    icon.setIconNames( QStringList() << iconName );
>>>>>>>    graph << iconRes;
>>>>>>>    res.setProperty( Soprano::Vocabulary::NAO::prefSymbol(),
>>>>>>> iconRes.uri() );
>>>>>>>
>>>>>>> to this:
>>>>>>>
>>>>>>>    Nepomuk::NAO::FreeDesktopIcon icon;
>>>>>>>    icon.setIconNames( QStringList() << iconName );
>>>>>>>    graph << icon;
>>>>>>>    res.setProperty( Soprano::Vocabulary::NAO::prefSymbol(),
>>>>>>> icon.uri()
>>>>>>> );
>>>>>>
>>>>>> nice.
>>>>>>
>>>>>> Cheers
>>>>>> Sebastian
>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Sebastian
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> http://quickgit.kde.org/?p=kde-runtime.git&a=blob&h=304db56a9aff5523a5672415550c49d4b7269c3c&hb=344806a2e378f3421399cad39a63f14a4428308b&f=nepomuk/services/storage/lib/nepomuk-simpleresource-rcgen.py
>>>>>>>> _____________________________________________


More information about the Nepomuk mailing list