implement new method find_events_templates_for_sets

[Seif Lotfy]

Basically here is what I want to do:
I want to be able to ask Zeitgeist for all events between 8:00 and 9:00 for the last 7 days
Right now I would need to call find_events 7 times
However a new idea would be find_events_sets which takes in an array of arguments that would be passed to find_events. This way we can call several sets of events at once :)

I have a branch missing a remote test... But before I continue I would like to know what you think...

[Seif Lotfy (seif)]

Here is my current branch for it
http://code.launchpad.net/~zeitgeist/zeitgeist/find_sets

[Seif Lotfy (seif)]

Here is a log of the decision:
------------------------------------

<thekorn> seif__: as I said before, I don#t like the idea of having such a method
<seif__> thekorn, i see it being very helpful for other ppl
<seif__> i think one dbus roundtrip is always better than n dbus roundtrips
<thekorn> seif__: what's wrong about calling FindEvents 7 times?
<thekorn> I don't think dbus roundstrips are bad
<thekorn> or expensive (performance wise)
<seif__> its more performant
<seif__> like in GAJ
<seif__> we want to draw the bottom bar
<seif__> instead of calling 90 times
<seif__> i call once
<seif__> can iget things cateogrized
<thekorn> there was even a talk at GUADEC last year, where a telepathy guy said: "do as much roundtrips as possilbe, instead of putting everything into one big method"
<thekorn> seif__: yeah, but: there will be 90 times more data to send, and it will take 90 times more time
<RainCT> do we have any benchmarks for this?
<thekorn> which roughly means 90 times more posssible timeouts
<thekorn> RainCT: no
<thekorn> we are pretty bad at doing benchmarks
<thekorn> and having sientific data of how much time we spend in sql,python,dbus etc
<RainCT> thekorn: Well, that's easy. SQLite: 50%, D-Bus: 50%, Python: 0%.
* RainCT hides
<thekorn> if it was so easy, I would go and rewrite linux in python
<seif__> thekorn, how can i make test cases print stuff
<seif__> i could test with that then
<seif__> actually my code will just reduce the dbus call
<seif__> nothing more than that
<seif__> everythning else is like calling find_event method several times
<seif__> unless
<seif__> RainCT, can work it out in a query of some sort
<thekorn> seif__: what do you mean with printing stuff?
<thekorn> seif__: but it will over complicate the API
<thekorn> let's keep it as simple and clean as we have it now
<thekorn> unless we find some issue or get requests
<thekorn> but arguments like "I find it helpful for other people" are not working for me in this case, sorry
<seif__> thekorn, it already demoed in GAJ
<seif__> GAJ has the worst startup time ever because drawing the bottom bar needs shits load or roundtrips
<seif__> and although i like RainCT's extension solution
<seif__> a I think a solution for the problem should be provided by the API
<thekorn> seif__: what do you think is so expensive about roundtrips?
<seif__> RainCT, you experience the same isseu
<seif__> so does mhr3
<seif__> we have t ocall 90 times to draw a graph
<seif__> so sending request and waiting for a reply
<seif__> 90 times is a lot
<thekorn> seif__: is it possible that the way the mainloop is prossed on the client is just broken (aka too slow)
<seif__> i doubt the client is broken
<mhr3> seif__, RainCT does it now with a single request afaik
<seif__> mhr3, yeah but my solution would do that too
<seif__> :)
<seif__> but in a more elegant way I guess
<mhr3> i dont like your solution, over-complicating the api is not a good solution
<mhr3> it only means the client is written in a bad way
<seif__> how is it overcomplicating
<seif__> its just putting the arguments as set in an array
<seif__> -.-
<mhr3> that's exactly overcomplicating