Hi Andy, hi Adam,
I understand the restxq stuff is in development/experimental and I wonder what plans you have in that direction? I think there are issues/limitations with the url limited to restxq/ and that xqm can be accessed directly (as text) etc, but one limitation of the spec seems to be that one can read a named header or cookie ( chosen at design time ) but not list all headers in the request. I wonder if an extension to get the full serialization of the request in the http:send-request response format might be useful. e.g. %rest:request("{$req}")
maybe we can start some join discussion on the future of RESTXQ? Christian
Yes that sounds good, im actually working on it right now.
I am trying to finish the implementation in eXist-db and have also spent some time to try and pull it out into a set of libraries without implementation specific parts, but there is still more to do there.
I then hope to write up the draft specification and get it to Balisage for late-breaking news, but we will have to see. Either way, comments and input are welcome :-)
Hope you are both well?
Cheers Adam.
On 6 May 2012 17:45, Christian Grün christian.gruen@gmail.com wrote:
Hi Andy, hi Adam,
I understand the restxq stuff is in development/experimental and I wonder what plans you have in that direction? I think there are issues/limitations with the url limited to restxq/ and that xqm can be accessed directly (as text) etc, but one limitation of the spec seems to be that one can read a named header or cookie ( chosen at design time ) but not list all headers in the request. I wonder if an extension to get the full serialization of the request in the http:send-request response format might be useful. e.g. %rest:request("{$req}")
maybe we can start some join discussion on the future of RESTXQ? Christian
Adam,
thanks for your quick feedback; great to hear you are working on new versions!
I then hope to write up the draft specification and get it to Balisage for late-breaking news, but we will have to see. Either way, comments and input are welcome :-)
The feature that we've been asked for most of the time is support for multipart requests. I'll be happy to provide with with more feedback,
Christian
Multipart has always been on the list, but as it adds complexity I wanted to get the initial draft specification out first.
On 6 May 2012 21:03, Christian Grün christian.gruen@gmail.com wrote:
Adam,
thanks for your quick feedback; great to hear you are working on new versions!
I then hope to write up the draft specification and get it to Balisage for late-breaking news, but we will have to see. Either way, comments and input are welcome :-)
The feature that we've been asked for most of the time is support for multipart requests. I'll be happy to provide with with more feedback,
Christian
Hi Adam,
Sounds good. eXist-db has various modules e.g. http://exist-db.org/exist/functions/request that can be used to fill in the gaps in RestXQ as currently defined. BaseX starts with an almost blank sheet. Multipart would be good, and also the @context parts of jax-rshttps://cwiki.apache.org/WINK/jax-rs-context-information.html . /Andy
On Sun, May 6, 2012 at 6:14 PM, Adam Retter adam.retter@googlemail.comwrote:
Yes that sounds good, im actually working on it right now.
I am trying to finish the implementation in eXist-db and have also spent some time to try and pull it out into a set of libraries without implementation specific parts, but there is still more to do there.
I then hope to write up the draft specification and get it to Balisage for late-breaking news, but we will have to see. Either way, comments and input are welcome :-)
Hope you are both well?
Cheers Adam.
On 6 May 2012 17:45, Christian Grün christian.gruen@gmail.com wrote:
Hi Andy, hi Adam,
I understand the restxq stuff is in development/experimental and I
wonder
what plans you have in that direction? I think there are issues/limitations with the url limited to restxq/
and
that xqm can be accessed directly (as text) etc, but one limitation of
the
spec seems to be that one can read a named header or cookie ( chosen at design time ) but not list all headers in the request. I wonder if an extension to get the full serialization of the request
in the
http:send-request response format might be useful. e.g. %rest:request("{$req}")
maybe we can start some join discussion on the future of RESTXQ? Christian
-- Adam Retter
skype: adam.retter tweet: adamretter http://www.adamretter.org.uk
Hi Andy,
Sounds good. eXist-db has various modules e.g. http://exist-db.org/exist/functions/request that can be used to fill in the gaps in RestXQ as currently defined.
Which gaps do you see modules filling?
BaseX starts with an almost blank sheet. Multipart would be good, and also the @context parts of jax-rs. /Andy
Multipart is on the list, I specifically didnt do @context, because I think there could be better approaches. But lets discuss when the draft is out?
On Sun, May 6, 2012 at 6:14 PM, Adam Retter adam.retter@googlemail.com wrote:
Yes that sounds good, im actually working on it right now.
I am trying to finish the implementation in eXist-db and have also spent some time to try and pull it out into a set of libraries without implementation specific parts, but there is still more to do there.
I then hope to write up the draft specification and get it to Balisage for late-breaking news, but we will have to see. Either way, comments and input are welcome :-)
Hope you are both well?
Cheers Adam.
On 6 May 2012 17:45, Christian Grün christian.gruen@gmail.com wrote:
Hi Andy, hi Adam,
I understand the restxq stuff is in development/experimental and I wonder what plans you have in that direction? I think there are issues/limitations with the url limited to restxq/ and that xqm can be accessed directly (as text) etc, but one limitation of the spec seems to be that one can read a named header or cookie ( chosen at design time ) but not list all headers in the request. I wonder if an extension to get the full serialization of the request in the http:send-request response format might be useful. e.g. %rest:request("{$req}")
maybe we can start some join discussion on the future of RESTXQ? Christian
-- Adam Retter
skype: adam.retter tweet: adamretter http://www.adamretter.org.uk
Which gaps do you see modules filling?
Well that request module has many things, in addition to multipart, that can not be accessed via the RestXQ of Prague 2012. But as you say, there may be better ways. Looking forward to see, and discuss more, when your next draft appears. /Andy
On Tue, May 8, 2012 at 1:10 PM, Adam Retter adam.retter@googlemail.comwrote:
Hi Andy,
Sounds good. eXist-db has various modules e.g. http://exist-db.org/exist/functions/request that can be used to fill in
the
gaps in RestXQ as currently defined.
Which gaps do you see modules filling?
BaseX starts with an almost blank sheet. Multipart would be good, and also the @context parts of jax-rs. /Andy
Multipart is on the list, I specifically didnt do @context, because I think there could be better approaches. But lets discuss when the draft is out?
On Sun, May 6, 2012 at 6:14 PM, Adam Retter adam.retter@googlemail.com wrote:
Yes that sounds good, im actually working on it right now.
I am trying to finish the implementation in eXist-db and have also spent some time to try and pull it out into a set of libraries without implementation specific parts, but there is still more to do there.
I then hope to write up the draft specification and get it to Balisage for late-breaking news, but we will have to see. Either way, comments and input are welcome :-)
Hope you are both well?
Cheers Adam.
On 6 May 2012 17:45, Christian Grün christian.gruen@gmail.com wrote:
Hi Andy, hi Adam,
I understand the restxq stuff is in development/experimental and I wonder what plans you have in that direction? I think there are issues/limitations with the url limited to
restxq/
and that xqm can be accessed directly (as text) etc, but one limitation
of
the spec seems to be that one can read a named header or cookie ( chosen at design time ) but not list all headers in the request. I wonder if an extension to get the full serialization of the request in the http:send-request response format might be useful. e.g. %rest:request("{$req}")
maybe we can start some join discussion on the future of RESTXQ? Christian
-- Adam Retter
skype: adam.retter tweet: adamretter http://www.adamretter.org.uk
-- Adam Retter
skype: adam.retter tweet: adamretter http://www.adamretter.org.uk
basex-talk@mailman.uni-konstanz.de
-
Adam Retter -
Andy Bunce -
Christian Grün