> 1. OMG code duplication: the entire contents of http-client.xq.src is copied
> (and modified?) from the original http-client module. That's nearly 3000 lines
> of some of the ugliest and most error-filled code we've got. No way do we want
> to maintain two copies of it. Also, they both call curl_global_init() and
> curl_global_cleanup(), which means that they will stomp on each other if
> anyone attempts to use both. This code must be consolidated somehow, perhaps
> into a common library that both modules use. Or, we need to simply eliminate
> the original http-client library. Perhaps we could replace the old http-client
> module with a pure XQuery wrapper module that replicates the old API, much
> like V2 of the EXPath http-client module does?
> 2. Need to consolidate the CMake code which searches for curl, etc. It was
> copied from modules/com/zorba-xquery/www/modules/CMakeLists.txt, and it still
> exists in that location. That means the search for CURL is done twice, and the
> cached variable ZORBA_HAVE_CURL is defined twice, and the Windows .pem files
> are copied twice... I would suggest that it should remain where it is in
> modules/CMakeList.txt, and be deleted from the other location, and testing
> done to ensure it still works right. (This issue would also be resolved by
> eliminating the original http-client module or replacing it with a wrapper
> module.)

Yes, part of the code of the json-http-client duplicates that of the original 
http-client-module. It is not 100% the same because, as you said, because 
the original contains several bugs. The bugs I found (which include, headers 
broken/absent charset encoding/decoding, broken/absent streamable string and 
support, error reporting, and so on) are fixed in the JSON HTTP module code.

I believe that removing the old http-client module would solve many problems, 
but given the widespread use of this module I am not sure if this is feasible.
I remember that when I started working on this module there was a discussion on 
this option and that keeping the old module (and duplicating the code) was the 
final decision.
However, my knowledge in this respect is limited, so I am not sure.

The next best thing would be to replace the old module with a wrapper.
The only downside of this is that some of the old module bugs are really 
e.g.: all requests which do not contain a manually specified "charset=UTF-8" 
specification in the media-type are sent with a wrong encoding.

Therefore, I will begin to work on the wrapper.
Your team Zorba Coders is subscribed to branch lp:zorba.

Mailing list: https://launchpad.net/~zorba-coders
Post to     : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zorba-coders
More help   : https://help.launchpad.net/ListHelp

Reply via email to