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.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.
In the mean-time you could also just put it in the pre-amble area, where the flag-for-followup stuff goes.
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.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?
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.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?
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.
