Better Buddy List Searching.

[Shubham Agarwal]

Hi Devel List,

My name is Shubham and I am student from yet-another-Indian-college and my
introduction will be yet-so-boring so I'll keep it short!
IamfrombitspilaniasmallcollegeinIndiaandinterestedincoding.

Phew, that was quick! Now let's get to some business here.

I have been reading on a few emails regarding buddy search and I have been
following leads of Sanket and Mark about how to go about it. I have some
solid ideas which I think can help make this project worth a summer scope.

To start off I used the following resources to increase my view about
problem structure. I was aghast when I saw so many people wanting a better
search in Pidgin, specially in this ticket [1]. I must say that we need to
buckle down and do something about it.

I think the project can consist of three methodological parts.
1. Try to modify/implement components of blist.c so that search can be
provided as a service rather than a one-off for Pidgin (and not Finch) only.
2. Incorporate this search functionality to Pidgin because most of our
traffic comes from there (well, I hope Sanket finishes his statscollector
soon!)
3. Include it in Finch which also shows that search can be used by other
clients.

Let's try to tackle one problem at a time, firstly

_[Part 1] Incorporating search in blist.c_
==============================
As my understanding goes blist.c contains chunk of the code for maintaining
PurpleBuddyList [2] which is a tree structure containing list of Buddies
(usually grouped in GROUP) and Chat etc. I think it's possible that we try
to modify parts of blist.c so that UI's (such as finch and pidgin) can
directly get a list of buddies with given search term. Hence, in my world
of search -- I just strip down results which have relevance to search
query. So suppose I consider a search tree like,

A
-- user1 at domain1.com (alias: Hulk)
-- user2 at domain2.com (alias: none)
-- user11 at domain3.com (alias: none)
B
-- user2 at domain3.com (alias: none)
-- user3 at domain3.com (alias: Spiderman)

A search with partial string "user" should essentially return the entire
tree. I see that it's not the behavior with Pidgin currently! Similarly,
string "Hulk" should return a result such as:

A
-- user1 at domain1.com (alias: Hulk)

We can debate about what parts of a contact to keep for search, but that
can be addons to a very basic functionality of searching a contact with
atleast it's Protocol Name (gmail id say) and it's Alias (set either by
server, or by Pidgin itself).

_Avoid O(n^2) style search_
======================
I have some interesting ideas about how to make this search efficient,
searching each time with the complete string will be in-efficient. Though
if we exploit the fact that search is generally Incremental (one character
up-or down) it'll be useful to keep track of what the last search was. For
example, if I already know that the result of query "user1" is:
A
-- user1
-- user11
(skipped complete details for brevity)

it's perhaps useful to keep this result stored (a PurpleBuddyList
*cached_search pointing to original list items) and then wait for the next
input and update etc.

It'll be interesting if we can keep some kind of mechanism (I haven't
thought of it) which can restrict the number of queries to the search per
second. Because if the user is typing quickly maybe he does-not want to see
all the intermediate results. But if it's not a performance issue we can
let it go.

_[Part 2] Implementing search in Pidgin_
===============================
Now that we have search API out of the way, implementing a search in Pidgin
is probably easier. Again this code should reside in gtkblist.c under
Pidgin/ directory. We need to provide a Search Box on top of Pidgin
buddy-list. I think this can be achieved by modifying structure of
PidginBuddyList [3]. After that is done, each press of Key (which we can
again capture using GTK signals "key-down" and "key-up" and "key-press")
the buddy list can be easily refreshed.

_Summary_
=========
I think if we consider the complexity of including a shiny new search API
and implementing it as part of Pidgin and Finch this project might be big
enough until the code gets checked into upstream.

I would love to hear the community thoughts about what they think about my
ideas.

[1] - https://developer.pidgin.im/ticket/1710
[2] -
https://developer.pidgin.im/doxygen/2.0.0/html/blist_8h.html#aae51ca059cce68d4cef484e85f17c38
[3] -
https://developer.pidgin.im/doxygen/2.0.0/html/gtkblist_8h.html#ad87f2528ebcc26821172d687c455d06
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20130428/2d68210c/attachment-0002.html>