Comment 18 for bug 670358

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.