On 05/10/2011 01:03 PM, Laura Dragan wrote: > On Tuesday 10 May 2011 11:05:11 Vishesh Handa wrote: >> Hey list >> >> I started working on the Resource Watcher last week. I haven't done much >> right now, but everything *has* to be done by Thursday ( hard-feature-freeze >> ). The code is present in the nepomuk/resourceWatcher branch in kde-runtime. >> >> Could all of you please comment on the API? Like the Datamangement api, this >> code will *not* go into kdelibs in 4.7. We are going to wait for it to >> mature a bit, and then push it into kdelibs (4.8). >> >> The ResourceWatcher is just a convenient interface over a dbus-api, so if >> you don't want to depend on kde-runtime, you can always just copy the code. >> :) >> >> I've attached the basic header file. >> > > Hi Vishesh, > > Thanks! I was looking fwd to something like this for a while :) > > 1 comment: > > If i understand this right: > > /** > * Emitted on addition of any statement of the form - > * <res> rdf:type <types>, where <types> may be any of the set types > */ > void resourceTypeCreated( const Nepomuk::Resource & res, const > Types::Class & type ); > > the name of the signal is telling me that a new type was created, which is > not the case. It could be instead > void resourceOfTypeCreated( const Nepomuk::Resource & res, const > Types::Class & type ); > or > void resourceCreatedOfType( const Nepomuk::Resource & res, const > Types::Class & type ); > None of the two sound too good, but will give a better idea of what it does.
How about resourceTypeAdded or resourceTypesChanged. BTW I think we are missing the inverse signal like: resourceTypeRemoved. Also I still do not like the usage of Nepomuk::Variant, mostly because that class is so damn ugly. That is why I did not use Resource or Variant in the DMS API. IMHO we should match the two APIs, ie. use Resource and Variant (or a replacement) in the DMS API, too or remove them from the resource watcher API. Cheers, Sebastian > and 1 question: > > Would it make sense to have a method that allows adding a query to be > watched? Either with the Query API (preferred) or just a SPARQL string.. > Following this thought, all the methods that are now in the ResourceWatcher > could be written as queries, and as such, they could be seen as predefined / > for convenience.. > I realize now that I don't know how you implemented the methods, so this > could be just how you did it :) > > > Cheers, > Laura > _______________________________________________ > Nepomuk mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/nepomuk > _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
