There have been quite an amount of concerns regarding, making CURL's library for HTTP Transport in C, LibCURL the first choice for our HTTP Sender as well as the HTTP Responder in the Axis2/C engine. Thus, the interest is to make the engine do the processing up to Layer IV and get CURL to handle Layer IV. This fact is strongly supported by means explaining the advantages of CURL's widespread implementation support for HTTP Transport.
However, Axis2/C is an engine designed to port to multiple platforms ranging from Mainframe to Mobile computers, and thus making it the widest as well as the most feature rich Web Services Engine written in C. Thus, I, for several reasons, believe, CURL shouldn't be our 1st choice in terms of transport, as it,
However, Axis2/C is an engine designed to port to multiple platforms ranging from Mainframe to Mobile computers, and thus making it the widest as well as the most feature rich Web Services Engine written in C. Thus, I, for several reasons, believe, CURL shouldn't be our 1st choice in terms of transport, as it,
- Introduces an additional dependency (MS Windows is a good example).
- Might have issues in terms of mobile platforms.
- Lesser control over the transport layer.
- Threading issues that may crop up.
- License issues that may change in time.
- Dependency on CURL's performance.
- Additional size in binary distributions.
These are only a few examples. Dinesh, has written a nice article to why he believes CURL must be made the 1st choice at [1]. Samisa, has replied to Dinesh, explaining why CURL should not be the 1st choice at [2]. This discussion is open for anybody else who wishes to contribute.
[1] http://nethu.org/2008/01/14/axis2c-default-http-transport-should-be-libcurl-based/
[2] http://wso2.org/mailarchive/wsf-c-dev/2008-January/003101.html
[1] http://nethu.org/2008/01/14/axis2c-default-http-transport-should-be-libcurl-based/
[2] http://wso2.org/mailarchive/wsf-c-dev/2008-January/003101.html
No comments:
Post a Comment