25 Oct
2012
25 Oct
'12
12:27 p.m.
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=5f813fd…
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
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd