Op 13-04-10 14:47, Sohail Somani schreef:

How is it compared to pugixml? pugixml is fast and has a XPath implementation but it is not as full an implementation as I'd like. It's also pretty easy to hack on.

I didn't know this library, but apparently it is a library that focuses on speed, not on a correct implementation of the standard. The XML standard is pretty strict, some think it is too strict. But when pugixml claims it is 'error-ignorant' I know I won't use it. Besides, there's no support for UTF-16 in pugixml and my guess is it won't get far when it comes to testing the W3C test suite.

What kind of W3C-based testing have you done for the XPath implementation? Are there even any tests?

In the tests subdirectory of libzeep you can find a makefile you can use to create two test applications. One for the W3C test suite and one for testing the XPath's.

In either case, how difficult is it to add missing functions? I see a hard-coded list. Would be extra awesome if I could add to this list at run-time but the need for that is very low. However, it could make some stuff easier. For example, there is no "max" XPath function in your code and I'd like to add one.

I've implemented the core XPath 1.0 function library. Other XPath functions are not supported, for now. But adding them is quite easy I think, it just involves exposing a bit more of the internals of the XPath implementation and come up with a way to augment this.

Will you also add a SOAP client? Pretty please :)

A SOAP client means you need a WSDL parser and a code generator. I always write my SOAP clients in Perl and Java, there's only one I ever wrote in C++. Writing a SOAP client is a bit more tricky than writing a server, you suddenly have to support all variants like RPC/encoded apart from only document/literal. But it is something I perhaps should have a look at. -maarten

AMDG Lars Viklund wrote:

On Wed, Apr 14, 2010 at 12:21:31AM +0200, Juraj Ivančić wrote:

...

As an interesting side note - while attempting to compile libzeep I found that VS 9.0 compiler does not recognize spelled logical operators ('or', 'not' and 'and') as C++ keywords. Furthermore, passing macros like or=|| on the VS command line causes internal compiler error. Putting them inside code as #defines is OK for VS, but gcc (correctly) refuses to preprocess this.

Aren't the alternative spellings like `or', `and' and such defined in <ciso646>?

C.2.2.2 Header <iso646.h> [diff.header.iso646.h] The tokens and, and_eq, bitand, bitor, compl, not_eq, not, or, or_eq, xor, and xor_eq are keywords in this International Standard (2.11). They do not appear as macro names defined in <ciso646>. In Christ, Steven Watanabe

on Tuesday, April 13, 2010 7:01 PM Steven Watanabe wrote:

C.2.2.2 Header <iso646.h> [diff.header.iso646.h] The tokens and, and_eq, bitand, bitor, compl, not_eq, not, or, or_eq, xor, and xor_eq are keywords in this International Standard (2.11). They do not appear as macro names defined in <ciso646>.

They aren't *supposed* to be, but I believe they *are* macro names in Visual Studio. Erik

Op 14-04-10 00:21, Juraj Ivančić schreef:

I wanted to give it a try but unfortunately it does not compile on windows. A little peeking around the code showed that there was some fork() calls as well as some unix specific IPC (socketpair). Also, ASIOs native_socket_type is used in some places. Is there any special reason for this? You are already using asio and great deal of boost, why not go all the way and be portable? I'd be glad to help here if I can.

It is an option to use this. I should put that code in some conditionally compiled part, I agree. There is also a plain vanilla version of the server code that uses boost::asio only.

Just out of curiosity - why does HTTP server spawn a worker process? Is it merely 'the unix way of doing things' or does it improve performance compared to keeping everything intraprocess?

That's because I have a server process running at our computer that serves several SOAP services to search biological and medical databanks. Some of these databanks are available worldwide while others are strictly for internal use. Now I have one main server process that forks several sub processes. These sub processes cannot access each others memory and so we keep the sensitive data separated from the worldwide data. Another huge advantage is that I can detect from the master process when a child dies (which can happen since it starts other sub processes itself). Now I can restart a client from the master and I don't have to have another way to monitor the entire server. And so the server process is started at boot time and continues running until the next reboot serving thousands of requests per day.

As an interesting side note - while attempting to compile libzeep I found that VS 9.0 compiler does not recognize spelled logical operators ('or', 'not' and 'and') as C++ keywords. Furthermore, passing macros like or=|| on the VS command line causes internal compiler error. Putting them inside code as #defines is OK for VS, but gcc (correctly) refuses to preprocess this.

I used to have those defined in code that was meant to compile on windows. I personally believe my code is much more readable with the textual operators. Thanks, -maarten

Op 14-04-10 09:56, Juraj Ivančić schreef:

On 14.4.2010 8:12, Maarten L. Hekkelman wrote:

...

Op 14-04-10 00:21, Juraj Ivančić schreef: It is an option to use this. I should put that code in some conditionally compiled part, I agree. There is also a plain vanilla version of the server code that uses boost::asio only.

Is this vanilla version available? I could not find it in libzeep SVN.

https://svn.cmbi.ru.nl/libzeep/branches/without-prefork/ You may still have to hack the zeep-test.cpp file since it contains some pthread signal blocking calls. I don't know how to replace them in Windows, sorry. -maarten

On 14.4.2010 13:31, Maarten L. Hekkelman wrote:

I've updated the branch, it now contains a VC solution file that can be used to build zeep-test.exe (tested with VC C++ Express 2008 on Win7).

Wow - that was fast. Thank you very much.