[Devel] SF.net SVN: openser: [2039] trunk/modules/presence

Klaus Darilion klaus.mailinglists at pernau.at
Wed Apr 25 09:30:33 CEST 2007



Anca-Maria Vamanu wrote:
> Hello Klaus,
> 
> You probably already know that for aggregating data which is available 
> from another device, a Publish message could be triggered through  MI, 
> using pua_mi.   And the data will be aggregated when sending Notify msg.
> However, in the case in which the info you what to add is dependent on 
> the received one(like the temperature in the room for eg), registering a 
> callback seems a good option. Another alternative is to filter the 
> Publish message in config file and trigger sending a Publish through MI 
> with the same expires.( it seems worse since it increasses message flow 
> and implies aggregating for each Notify).
> If not dependant, it is an inconvenient to wait for a Publish to say 
> what you want to say.
> Is the callback mechanism appropriate for what you had in mind?

Hi Anca!

I thought of the following example:

A SIMPLE client PUBLISHes its presence to openser. The PIDF contains the 
presence of the client. Now, I have an external system which knows the 
location of this SIP client, and I want to add the location to the 
presence (thus, adding the PIDF-LO to the PIDF XML body). Then, the 
NOTIFYs sent contain not only the presence, but also the location and 
clients which support PIDF-LO can display the location too.

btw: If I manipulate the body of a received PUBLISH with textops before 
calling handle_publish() - does the presence module store the modified 
body or the original received body? Thus are lumps processed before 
saving the body, or e.g. applying fix_natted_contact?

regards
klaus

> 
> regards,
> 
> Anca
> 
> 
> 
> Klaus Darilion wrote:
> 
>> Hi Anca!
>>
>> I have another (IMO interesting) idea. What about allowing other 
>> modules to register a callback function just before PUBLISH body gets 
>> written into the presentity table.
>>
>> E.g. presence module, just before it will write the XML payload into 
>> the presentity table, will execute the callback function, allowing 
>> registered modules to modify the XML body. Then the presence module 
>> stores the modified body into the presentity table. Further, 
>> activation on the body manipulation callback can be 
>> activated/deactivated from openser.cfg by setting a flag.
>>
>> This would allow to modify published data e.g. for aggregating data 
>> which is available from external components.
>>
>> what do you think of this?
>>
>> regards
>> klaus
>>
>> Anca-Maria Vamanu wrote:
>>
>>> Hello,
>>>
>>> It should be implemented in presence module. Only it has acces to 
>>> presentity_table and active_watchers table and in here notifications 
>>> are generated.
>>> Moreover this function could be generaly used no matter the event.
>>>
>>> regards,
>>>
>>> Anca
>>>
>>> Klaus Darilion wrote:
>>>
>>>> Hi Anca!
>>>>
>>>> I'm thinking about an MI function for resending NOTIFYs.
>>>>
>>>> E.g. if the presence of an user is updated by an external 
>>>> application which writes directly into the presence table (instead 
>>>> of sending a PUBLISH) I want to trigger NOTIFYs to the watchers by 
>>>> calling this MI function.
>>>>
>>>> Question: Where should this MI function be implemented? In presence 
>>>> or presence_xml module?
>>>>
>>>> regards
>>>> klaus
>>>>
>>>> Anca Vamanu wrote:
>>>>
>>>>> Revision: 2039
>>>>>           
>>>>> http://openser.svn.sourceforge.net/openser/?rev=2039&view=rev
>>>>> Author:   anca_vamanu
>>>>> Date:     2007-04-23 00:28:35 -0700 (Mon, 23 Apr 2007)
>>>>>
>>>>> Log Message:
>>>>> -----------
>>>>> -  Restructured the module to handle PUBLISH and SUBSCRIBE messages 
>>>>> and generates NOTIFY messages in a general, event independentway. 
>>>>> It allows registering events to it from other OpenSER modules. 
>>>>> presence_xml module adds events: presence, presence.winfo, dialog;sla.
>>>>> Modified Paths:
>>>>> --------------
>>>>>     trunk/modules/presence/README
>>>>>     trunk/modules/presence/doc/presence.sql
>>>>>     trunk/modules/presence/doc/presence_devel.sgml
>>>>>     trunk/modules/presence/doc/presence_user.sgml
>>>>>     trunk/modules/presence/event_list.c
>>>>>     trunk/modules/presence/event_list.h
>>>>>     trunk/modules/presence/notify.c
>>>>>     trunk/modules/presence/notify.h
>>>>>     trunk/modules/presence/presence.c
>>>>>     trunk/modules/presence/presence.h
>>>>>     trunk/modules/presence/presentity.c
>>>>>     trunk/modules/presence/publish.c
>>>>>     trunk/modules/presence/subscribe.c
>>>>>     trunk/modules/presence/subscribe.h
>>>>>     trunk/modules/presence/utils_func.c
>>>>>     trunk/modules/presence/utils_func.h
>>>>>
>>>>> Added Paths:
>>>>> -----------
>>>>>     trunk/modules/presence/bind_presence.c
>>>>>     trunk/modules/presence/bind_presence.h
>>>>>
>>>>>
>>>>> This was sent by the SourceForge.net collaborative development 
>>>>> platform, the world's largest Open Source development site.
>>>>>
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> Devel at openser.org
>>>>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>>>
>>>>
>>>>
>>>
>>
> 



More information about the Devel mailing list