Hi, Just wanted to say that we have a very similar use case (though not SOAP) of a standard requiring having one endpoint to receive all incoming requests. Some of these requests are updating and some are not.
At the moment, it seems like the only solution will be to have two endpoints (one for updating, one for not) and another service sitting in-front of BaseX that peers into the incoming message to determine which ones are updating or not before forwarding them onto the correct service.
Should we go ahead and setup something like this? Or does anyone have a more elegant suggestion?
Cheers, -carl
On Jan 14, 2014, at 9:49 AM, Christian Grün christian.gruen@gmail.com wrote:
functions where few of them are updating and few are not. I necessarily have to declare the soap entry point as updating too. Thus introducing particular syntax like db:output or synchronizations in places where it's not supposed to be needed. Isn't it like that?
Yes, I think I see the point. I would like to get completely rid of the db:output statements, as it can statically be deteted if a query is updating or not anyway. XQuery Update 3.1 might provide some ways out of the current situation.
I think it depends on the content type. I'm trying with firefox poster and it works if I force application/x-www-form-urlencoded. Conversely it stops working with
curl -i -XPOST -d"<a/>" -H "Content-Type: application/xml; charset=UTF-8" "localhost:8984/test"
Ok. If it’s requests are sent without a content type, the received value could be cast to XML via fn:parse-xml; but that may not be helpful in your case.
I’ll have some more thoughts if there are chances to also forward the request content. It may take while, though..
Christian _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk