[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