Re: [Evolution-hackers] Bug #127546 Gaim Evolution presence integration.

[Not Zed <notzed ximian com>]

On Sat, 2004-09-11 at 06:21 -0400, praveen kandikuppa wrote:
> Thanks for your input, I have a few questions and comments though.
>
> The way it currently works format_message in emformathtmldisplay calls
> format_message in emformathtml which actually does the formatting for
> header. How should i insert the html code with object tag and class id
> into CamelStream. I was considering introducing something like
> format_presence/format_header which can be put as virtual functions
> and only implemented by emformathtmldisplay or is there a better way
> to do this without messing with those internals.
Hmm, it probably needs a virtual format_header function.  But looking at the code it might not be that easy to split out, although there are already re-usable structures and so forth to describe the headers.  And there's way too much stuff in format-message to want to duplicate it.

In the mean-time you could also just put it in the pre-amble area, where the flag-for-followup stuff goes.
> Previously i was using a messageid<->contactid cache. Is that
> necessary?? Because while moving over to PObject based display of
> presence info, i have also removed the caching code.  The caching code
> was implicit in the EMIMPresence which listened to message list->sent
> addressbook queries->cached the result->sent presence queries->updated
> the html display. Since everything now except the caching part is done
> by the new EPresenceIcon, I had removed EMIMPresence and along with it
> caching is gone. So what happens now is an addressbook query is
> performed for each message displayed.  I can still use caching and is
> very simple to implement but is it really needed?
I guess it would depend on if it returns in a reasonable timeframe anyway.  The display MUST be threaded anyway, and MUST be async and cancellable, so any actual delays wont impact the display itself.

> Presence information in contact display which also uses html is
> displayed using the uri "internal-contact-uri". It was being used
> previously to display contact photos and i modified it to use buddy
> icons where available. Should that also be modified to use PObject?
The contacts component does its own thing, I have no idea how it works.  It definitely doesn't use EMFormat though, so you can't use a PObject, nor does it use threads.
> Also as a note, the functions which lookup presence information are
> really asynchronous, They may feel synchronous because the time taken
> to issue a query to gaim-remote and get back the reply is nearly 5-10
> ms. The addressbook lookup for from address itself is ansynchronous. 
> Also there is a cache in place (e-util/e-impresence.{c,h} -- this is
> where the global variable is used as the cache is common for
> mail/addressbook parts) for contactuid<->presence info and actual
> query using gaim-remote only takes place if either the information is
> not present in the cache or requery is requested explicitly. Recaching
> is done to update the cache information periodically and any updated
> info is pushed back to the UI for redisplay. This is so that the
> presence information displayed does not become outdated. One more
It seems to me the request is sent and a re-display is done later should it update.  If you used a custom widget you could just (re) display the widget, you should not have to re-format the whole mail display which will be annoying anyway (i'm talking about the mail case).
> question is -- is caching of presence information needed or what i am
> doing above is unecessary? Also should presence information be fetched
> from gaim each time it is requesed. Fetching the presence information
> currently involves going through all the screen names in the contact,
> sending out a query for each and returning the info for all the
> screennames. At the time i felt that this was a little too much to be
> done for each presence request and caching was better.
>
> I also have a patch to use galago as one of the backend for looking up
> presence information. But it currently lacks fetching buddy icons and
> also sending out message requests as it is not implemented in galago
> itself. The next set of patches will contain that. I will also be
> writing a somewhat detailed note on how the different things are
> modified in e-text/addressbook/gaim-remote.
>
> Is everyone busy with gnome 2.8  or is there is not much interest in
> the bug becuase i have not received any other comments regarding this
> patch and also my previous questions on this list went nearly
> unanswered.

Probably some of all.  Everyone in the team are busy with the 2.0.0 release, or moving onto new things.