For anyone who doesn't know the language, Objective C seems like a cruel joke that got out of hand. Even the creators' names seem like a joke. (If you don't know the names, you should look them up.) It can include all native C libraries into it directly, which is what brought me, and others, to use xmlrpc-c with Objective C in the first place.
The problem is that the Objective C programming model is distinctly adverse to code that blocks, which is similar to many GUI toolkits. This is the reason that I began to put together an alternative in the first place. My eventual goal would be to expand out the existing XMLRPC-C library to have an available asynchronous API using the LibCurl multi interface, which would be useful with the various GUI toolkits, Mac, Linux, and Windows alike.
Objective C is experiencing huge growth and I would like to have a working framework available and proximal to the XMLRPC-C code to allow other developers to use, and not have to spend the hundreds of hours debugging multi-threaded code for obscure bugs, as I had to.
What I have built is a single framework (XMLRPC.framework). I use a single main header file (xmlrpc.h) within it that includes all other necessary headers. I'm cleaning up the code a bit now and I'll send out a copy of it to the list later this week.
On Feb 7, 2011, at 9:07 PM, Bryan Henderson <bryanh@...> wrote:
> As project maintainer, my first reaction is resistance, because I don't
> know anything about Objective C and it seems like it could be a considerable
> burden for me to package this and ensure quality.
> On the other hand, it does seem to fit the package as well as C++ does, and
> it's hard to say no to just disseminating files.
> And I doubt there would be much demand for service.
> What exactly is the form of your code and what sort of packaging do you have
> in mind?
> Bryan Henderson San Jose, California