Well, we have a long way to go, but already it feels promising.
If you pick up the server tree from cvs, it should build happily on fedora3 and probably most other linux distro's. Please give it a try. There are some client test binaries that get built, as well as the WSDL file for consumption by your favorite java SOAP toolkit.
please see the readme to get going...
-tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, busy playing with it at the moment. Had some trouble installing gsoap, as it dragged in 4 million dependances on gnome development packages, but it seems ok. Now busy downloading sleepycat and then will try the compile.
I don't see a wsdl anywhere, I assume it's generated by the build process? My only concern is if it contains any complex object types - the more we can stick to strings and other primitives, the easier it will be.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The wsdl is generated at build time. It should be very simple. Here's a small breakdown of marshalled types:
Input args are all simple xsd:strings.
Returned XmlDocuments are also xsd:string elements containing the raw xml of the doc. XmlResults are returnded as an xsd:sequence of xsd:strings with each xsd:string containing the raw content of the underlying XmlValue.
I'm not sure how much more simpler it can be :)
I've done quite a bit of work w/ SOAP, and i have more small things to do w/ the interaction like set it to use doc-literal encoding so it will play nice w/ the .net stuff, that doesn't support rpc-literal encodings.
Theses are all known items. I mainly just wanted to get a base line into cvs yesterday, so you can start testing, and developing.
Today, I am going to add some more reflection re: containers available, stats like doc counts, and the ability to add/change/drop indexes, and maybe even extend meta-data attributes.
I also want to add somemore flexility as far as dynamically growing the worker thread pool as load increases, and then shrinking when loads subside, etc...
More importantly, i will have the build package up a client side library, and then swig the simple interface into java. Those are really easy, as the client library is already being built as a support lib, and swig is very easy once you know it...
-tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So far, it looks wicked.
I was a little suprised at how it build tho - I though an Apache module was something we drop into an Apache server (similar for example to a php module), but your build actually generates a stand-alone binary.
But I quite like it - makes distribution a lot easier.
By the way, check out the (growing) Bug a Feature request tracker - I'm adding in stuff as I see it, so it will grow dynamically,and allows us to keep track better than communicating in the forums.
Very good work so far, can't wait to hack together my first Java invocation.
Looks like the wsdl is simple enough for me to consume without any trouble.
PS I have done lots of stuff with swig in the past, it does make things quite easier in some cross-language applications.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, knocked off some good ones today. Added a home page for the server, server can provide its own wsdl file upon request. FIXED that stupid bug w/ the worker threads die'ing 1 by 1 as timeouts hit on accept() calls. did some code formatting, and some additions to the build process, etc.
Also added a get_container_list() SOAP method so we can ask the server for a list of available containers.
its all in CVS so pls check it out!
thanks,
-tom
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, we have a long way to go, but already it feels promising.
If you pick up the server tree from cvs, it should build happily on fedora3 and probably most other linux distro's. Please give it a try. There are some client test binaries that get built, as well as the WSDL file for consumption by your favorite java SOAP toolkit.
please see the readme to get going...
-tom
OK, busy playing with it at the moment. Had some trouble installing gsoap, as it dragged in 4 million dependances on gnome development packages, but it seems ok. Now busy downloading sleepycat and then will try the compile.
I don't see a wsdl anywhere, I assume it's generated by the build process? My only concern is if it contains any complex object types - the more we can stick to strings and other primitives, the easier it will be.
The wsdl is generated at build time. It should be very simple. Here's a small breakdown of marshalled types:
Input args are all simple xsd:strings.
Returned XmlDocuments are also xsd:string elements containing the raw xml of the doc. XmlResults are returnded as an xsd:sequence of xsd:strings with each xsd:string containing the raw content of the underlying XmlValue.
I'm not sure how much more simpler it can be :)
I've done quite a bit of work w/ SOAP, and i have more small things to do w/ the interaction like set it to use doc-literal encoding so it will play nice w/ the .net stuff, that doesn't support rpc-literal encodings.
Theses are all known items. I mainly just wanted to get a base line into cvs yesterday, so you can start testing, and developing.
Today, I am going to add some more reflection re: containers available, stats like doc counts, and the ability to add/change/drop indexes, and maybe even extend meta-data attributes.
I also want to add somemore flexility as far as dynamically growing the worker thread pool as load increases, and then shrinking when loads subside, etc...
More importantly, i will have the build package up a client side library, and then swig the simple interface into java. Those are really easy, as the client library is already being built as a support lib, and swig is very easy once you know it...
-tom
So far, it looks wicked.
I was a little suprised at how it build tho - I though an Apache module was something we drop into an Apache server (similar for example to a php module), but your build actually generates a stand-alone binary.
But I quite like it - makes distribution a lot easier.
By the way, check out the (growing) Bug a Feature request tracker - I'm adding in stuff as I see it, so it will grow dynamically,and allows us to keep track better than communicating in the forums.
Very good work so far, can't wait to hack together my first Java invocation.
Looks like the wsdl is simple enough for me to consume without any trouble.
PS I have done lots of stuff with swig in the past, it does make things quite easier in some cross-language applications.
Ok, knocked off some good ones today. Added a home page for the server, server can provide its own wsdl file upon request. FIXED that stupid bug w/ the worker threads die'ing 1 by 1 as timeouts hit on accept() calls. did some code formatting, and some additions to the build process, etc.
Also added a get_container_list() SOAP method so we can ask the server for a list of available containers.
its all in CVS so pls check it out!
thanks,
-tom