On 07/22/2010 01:25 PM, Ivan Čukić wrote: >> 1. Methods that return Nepomuk::Query::Query objects > > For the time being we could go for this one. We could always add (4.) > if needed (if we or somebody else finds it useful to have) later.
OK, then how one method combined with an enumeration? Maybe in a dedicated namespace or even in the Nepomuk::Query namespace as a generic access to typical queries used very often. Cheers, Sebastian > Eventually, we could even turn this into a data model or something > like we have for files. > > Cheerio, > Ivan > > p.s. You've forgotten to cross-post :) > > original message: >> 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. > _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel