Sorry to ruin the party, but I really don't like any of the proposed solutions. The use cases described in the wiki seems very academic and more intended on doing some theoretical counting exercises than solving actual user problems.
Unless we have some crystal clear use cases (fx. a UI mockup someone actually wants to develop and deploy) or a very clear idea on how we can extend and adapt those cases to other situations I don't think it makes sense to add new API. It will just be technical debt. Concerning the actual proposals (minding that I don't think we're at a place where it makes sense to discuss it yet): Seif: I think this is way too simple. We *also* need something where you can also do a query and do the counting in one roundtrip - preferably with one SQL call under the hood. I say also because there are situations where you want to display the events fast, and can wait a bit longer to display the counts - because the counting is often a slower task. Markus: Your proposal is more flexible, although I wonder why you use a double. It would seem very awkward to have to convert everything from double to int in most cases. Maybe a variant which type is determined by the ResultType you pass in? Regarding ResultType.MostFrequentActor this is identical to our current ResultType.MostPopularActor, right? Like the initial use cases I think the examples you add a somewhat contrived. Again, sorry if I come out as overly negative. I just feel like we're taking stabs in the dark here. _______________________________________________ Mailing list: https://launchpad.net/~zeitgeist Post to : zeitgeist@lists.launchpad.net Unsubscribe : https://launchpad.net/~zeitgeist More help : https://help.launchpad.net/ListHelp