12 Oct
2014
12 Oct
'14
10:17 a.m.
On 12/10/14 09:56, Juha Heinanen wrote:
Juha Heinanen writes:
Haven't used it in db_mode=2, but given
that pua is an user-agent
emulator, it is a matter of interaction from other modules as well. So
far, the main usage in my side is for publishing dialog-info states,
which works very well.
I had in mind that presence modules needed always to keep references in
cache, but then I assume now that the db only mode lacks proper
constraints in working with database, which should be easy to fix.
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
how should this be fixed? is it enough to always
add etag value to the
query or should also pres_uri be added just in case etags for different
pres_uris would match? or perhaps the best fix would be to skip the
query altogether in send_publish if etag is null?
i tried the latter in
pua/send_publish:
if (dbmode==PUA_DB_ONLY)
{
if (publ->etag) {
memset(&dbpres, 0, sizeof(dbpres));
dbpres.pres_uri = &pres_uri;
dbpres.watcher_uri = &watcher_uri;
dbpres.extra_headers = &extra_headers;
presentity = get_record_puadb(publ->id, publ->etag,
&dbpres, &res);
}
then also the initial publish for the second pres_uri was generated
correctly without sip-if-match header. however, now when 200 ok with
sip-etag header was received from presence server, pua did not insert
second record to pua table, but updated etag of the existing record of
the other pres_uri!
looks to me that pua module is pretty badly broken and i'm the first
ever user who tries it in db_mode=2.