Hi all,

Sorry for the late response, I've been busy with the overwhelming amount of 
replies ;-)

So, I just committed the first part of this, the new 'xcap' module. It exports 
the db_url, xcap_table and intergrated_server parameters and a single function 
(for now) parse_xcap_uri. I modified presence_xml, rls and xcap_client to make 
use of these.

Next step will be to merge my OMA external references support code and move 
some more common code to this new xcap module.

This is only present in trunk, but if anyone runs into issues related to this 
please let me know.


Regards,

On Nov 8, 2012, at 11:05 AM, Saúl Ibarra Corretgé wrote:

> Hi all,
> 
> I've been working for quite a while now in adding external references to RLS 
> and pres-rules documents following IETF and OMA specifications respectively. 
> And it works! \o/ In the process I noticed there is common behavior that can 
> be factored out of rls and presence_xml modules. So, my plan is to create a 
> new module called "xcap" (surprise surprise!) which encapsulates XCAP related 
> stuff and then both rls and presence_xml would use it in conjunction with 
> xcap_client.
> 
> These are the main things that would go into the new xcap module:
> 
>       - xcap_table: table where documents are stored
>       - integrated_xcap_server: boolean flag indicating if a integrated 
> server (as OpenXCAP) is in use or xcap_client should be used instead
>       - xcap_server: list of local XCAP servers
>       - functions to load arbitrary XCAP documents from DB
>       - functions to load an arbitrary node from a document using XPath
>       - XCAP URI parsing
> 
> Note that this change implies that the same table is used for XCAP documents 
> for both Presence and RLS. I see no reason to keep separated parameters in 
> RLS and Presence modules, so if anyone has a good reason for it, please speak 
> up so I can convince you otherwise :-)
> 
> 
> OMA pres-rules related changes:
> 
> Currently the pres_rules_auid and pres_rules_filename options are only used 
> in non-integrated XCAP mode, and pres_rules_auid may take any value. The 
> value for pres_rules_auid will be constrained to "pres-rules" or 
> "org.openmobilealliance.pres-rules" and will also be used in integrated mode. 
> The chosen AUID defines how the policy is applied, either following IETF 
> rules or OMA rules. After this implementation is complete, a way for choosing 
> the policy type per subscriber will be researched.
> 
> Right now both IETF and OMA pres-rules documents are stored with the same 
> "doc_type" thus overriding each other. This will no longer be the case. Users 
> will be able to store both types of documents and the proxy will apply the 
> rules according to the configured AUID. OpenXCAP will also be modified 
> accordingly.
> 
> 
> About xcap_server configuration option:
> 
> Currently it's only used in non-integrated mode, but it's also needed in 
> integrated mode on order to know if a reference is local or not and thus if 
> it should be followed or not.
> 
> 
> You made it this far! Great, what is your take on this?
> 
> Regards,
> 
> --
> Saúl Ibarra Corretgé
> AG Projects
> 
> 
> 
> 
> _______________________________________________
> Devel mailing list
> [email protected]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

--
Saúl Ibarra Corretgé
AG Projects




_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to