On 5/19/07, Robert McQueen <<a href="mailto:robert.mcqueen@collabora.co.uk">robert.mcqueen@collabora.co.uk</a>> wrote:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Abner Jose wrote: > What about aliasing? Will it work in the same way as Avatar? It's a different problem to avatars because often aliases are pushed to you, and it's not often it requires a round-trip to the server. The idea I had for aliasing was that we could leave the existing API as-is, with RequestAliases, but also add a function GetAliases, which would return the current known value of any cached/received/heuristically-determined aliases, but also potentially sending off some longer-running requests which would return AliasChanged later.</blockquote><div> Great idea. Probably it'll help a lot, because I don't know why, but RequestAlias takes a long time to return. Seems to be the most expensive of all when we're testing an IM client. (We've tested it on colligo, but probably is because it blocks the ui) </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On a similar note, I was considering an API on the Connection, something like ContactQuery, or the turbo-handle inspector, which would take a load of handles and return you a sparse dictionary for each, containing any information known about them keyed by identifiers, eg 1 could be string value of the handle, 2 could be the alias, 3 could be the presence, 4 could be the avatar token, 5 could be the handle owner (if the given handle was channel specific). Also, the return value could include opportunistic results about any owner handles (in the same way that DNS queries can return extra relevant results). It could also have the semantic of sending off any relevant long-running queries, and later emitting signals when this information was received. The intention would be to reduce bus-roundtrips (which are the real performance killer) when e.g. joining a channel, or receiving an invitation from someone, etc: rather than querying 3 or 4 different methods for handle x y and z, you can immediately make 1 method call for [xyz] and scrape out any info the connection manager has about them at the moment, and hook the signals for any subsequent updates.</blockquote><div> This is awsome!! I love that, but is there no problem to pass a big bunch of data through dbus? I mean,  handle uri +  presence + alias + avatar (data) + extra infos about contact. Well anyhow I don't think it'll be so big ... </div> </div>BR -Abner -- Abner José de F. Silva INdT - Instituto Nokia de Tecnologia <a href="mailto:abnerf@gmail.com">abnerf@gmail.com </a>