[Bug 26590] GetFrequentContacts

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=26590

--- Comment #15 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-10-11 04:05:44 PDT ---
11:00 < smcv> danni: when you say Identifier do you implicitly mean the 
              identifier of a *contact* (and not a chatroom or a bee or 
              something)? I think it'd help clarity if you said so
11:01 < danni> smcv: it could also be a chatroom
11:01 < danni> which cassidy dislikes
11:01 < smcv> that's not GetFrequentContacts, that's GetFrequentEntities or 
              something

11:04 < smcv> how does the logger know how many contacts to return? is it a 
              hard-coded number or frequency threshold?
11:05 < smcv> that sounds uncomfortably like "if Empathy's UI design wants to 
              show more than Meego's, one of them has to patch the logger"
11:05 < danni> smcv: it actually returns all of them
11:05 < smcv> is that a guarantee?
11:06 < smcv> that doesn't sound as though it scales tbh

11:08 < danni> smcv: the idea was to be able to build a recency based contact 
               roster
11:08 < smcv> danni: right, for that you want "the rankings among the N most 
              recent have changed"
11:09 < smcv> danni: or "the contacts with frequency >= 0.6 have changed"
11:10 < danni> smcv: where it gets messy is when all the frequencies change 
               once a day
11:11 < danni> I'd forgotten what a hack that signal was :-/
11:11 < smcv> couldn't the UI just poll every n hours? :-)
11:12 < danni> smcv: yeah, certainly
11:12 < smcv> or the signal could have no actual content, just "poll now"
11:12 < danni> doesn't that have the scaling problem still?
11:12 < danni> the signal could include the frequency of just the changing 
               contact
11:13 < smcv> frequency and rank order?
11:13 < smcv> perhaps?
11:14 < danni> actually, I think the signal is only meant to give entities whos 
               frequency has changed
11:15 < danni> it's just an a(sd) in case there's more than one entity

As far as I can tell, the idea is to be able to display the N most frequent or
most recent contacts (where N ought to be chosen by the UI rather than the
logger), or to be able to display contacts whose frequency/"recency" is above a
threshold (which should perhaps also be chosen by the UI, but the UI can only
usefully do that if it knows what the numbers mean).

If you're not sure what the semantics are yet as regards little details like
multiple-entity signals, whether an entity is a contact or a (contact|room),
etc., then writing them down would probably help :-)

I think having a bitmask for the contact/room/both choice seems like premature
optimization. If you want it to be in terms of handle types, I'd just have an
'au', Handle_Type[]; if the first thing the implementation does is to convert
that into a non-API bitfield, then that's fine.

For choices between contacts and (contacts|rooms|both), or between IMs,
"abstract events" and (IMs|calls|both|...), I really can't say anything without
a use case. What information is it that you actually want?

I can imagine wanting to have some global idea of frequency, in which an IM is
worth one point and a call is worth N points, or something.

I can also imagine wanting to have a call UI list the most frequently called
contacts, have a text UI list the most frequently messaged contacts (not the
same, at least on my phone), and have the address book list a mixture of the
two...

I'd tend to err on the side of the logger providing data, and UIs choosing
their interpretation, particularly if in practice we want to pipe this
information through Folks for per-metacontact aggregation before the UIs
interpret it?

You can't really measure chatrooms on the same scale as contacts (even a
not-very-noisy room like #telepathy can easily log more messages than a long
1-1 conversation) and I don't think the user's interaction with chatrooms is
the same either, so it doesn't necessarily make sense to force contacts and
rooms into one API if they don't actually want the same semantics.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.