On 07/22/2010 11:06 AM, Ivan Čukić wrote: >> For me that always was nepomuk queries but maybe it would be nice to >> have convenience methods for some special cases. > > The problem with this approach is that people would need to know how > we save the data so that they could write queries. Most of the time, > for simple things, this would be too much for a > not-interested-in-nepomuk devs to do. > > Other thing is that we'd get a lot of code duplication - just imagine > that everybody implements its own query and logic for the File > > Recent Documents menu. > > And the third reason for the convenience methods - we can later modify > the inner-stuff without changing the apps.
agreed. One question that remains: How do we do that? We have the following possibilities: 1. Methods that return Nepomuk::Query::Query objects 2. Methods that return a Nepomuk::Query::QueryServiceClient (weird) 3. Methods that return a list of results (blocking and thus, no good) 4. Methods that return a custom class which emits the results one by one 4.1. emit results as Nepomuk::Query::Result objects 4.2. emit results as custom objects I like 1 the best - mostly because I find working with Query object so convenient. 2 and 3 are not great and 4 is the most work. The question is whether it is worth the trouble. To answer that I suppose we need some use cases. Cheers, Sebastian _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
