Hi Daniel,

I added parsing of the auid just so that errors wouldn't be generated if we received it and so that these requests could then be handled cleanly. By parsing the auid in the xcap_server without errors it also leaves open the option of then calling an exported function from another module that does handle XQuery based searches, or simply returning an appropriate HTTP response code indicating that search isn't supported.

For example,

event_route[xhttp:request] { ... switch($rm) { ... case "POST": if ($xcapuri(u=>auid)=~"search") { if ($xcapuri(u=>target)=~"org.openmobilealliance.user-profile/users") { # Call custom XQuery search function for user-profiles } else if ($xcapuri(u=>target)=~ .. some other searchable directory .. ) { # Call custom XQuery search function for this directory } else { xhttp_reply("501", "Not Implemented", "", ""); } } else { xhttp_reply("400", "Bad Request", "", ""); } exit; } ... }

Regards,

Peter

On Thu, 2012-10-25 at 11:06 +0200, Daniel-Constantin Mierla wrote:

Hello Peter,

regarding your email with supported auids: http://lists.sip-router.org/pipermail/sr-users/2012-September/074850.html

You mention that org.openmobilealliance.search is not supported, but in the source code it is parsed. Is it that just is not complete implementation? I saw there is some special handling when this auid is matched.

Btw, I refactored a bit the auid discovery, using a static table that contains the list of supported auids: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5f813fda...

Hopefully I haven't introduced any issue, having limited testing capabilities for xcap at this moment (just commit fixes if you find some).

Also, if you know the auids that imply static documents (as you wrote in the email), feel free to add them when you get some spare time, it would be good to support them in xcap_server even the presence modules have to be extended as well.

Cheers, Daniel