libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] New project: microhttpd.h or microhttpd2.h?


From: silvioprog
Subject: Re: [libmicrohttpd] New project: microhttpd.h or microhttpd2.h?
Date: Wed, 28 Mar 2018 23:56:27 -0300

Thanks for answering Christian, it made clear!

I'll stay in stable 0.9* API. Anyway I found new deprecated flags, so I'm going to take a time to upgrade some examples and the documentation (e.g. using MHD_USE_INTERNAL_POLLING_THREAD instead of deprecated MHD_USE_SELECT_INTERNALLY etc.).

On Sun, Mar 25, 2018 at 6:33 AM, Christian Grothoff <address@hidden> wrote:
On 03/25/2018 04:05 AM, silvioprog wrote:
> Hello.
>
> I'm going to create a new project from scratch that uses MHD as main
> HTTP library, so I'm free to choose a new API. However, I have some
> questions that may help me to choose between microhttpd.h and microhttpd2.h:
>
> * can I use the new API in production? (I'm following MHD changes, but
> I'm not sure about the new API development status)

No. It compiles, but there are chunks of code missing to even get the
minimum things to work.

> * will the previous API still receiving new features and updates?
> (specially for websockets)

If necessary, sure. I expect to maintain both APIs for years in parallel.

> * is there a tutorial or reference to study the new API? (this two
> documents of the previous API helped me a lot: 1

Not yet.

> <https://www.gnu.org/software/libmicrohttpd/tutorial.html> / 2
> <https://www.gnu.org/software/libmicrohttpd/manual/libmicrohttpd.html>)
> * is there examples or tests (even drafts) showing how to use the new API?

Not yet.

> I'm OK to study (and contribute) the new API and I'm inclined to choose
> it because its simpler/friendly functions, MHD_Action etc., but if you
> don't recommend to use it for while I'm happy using the current stable
> API anyway. ;-)

Always happy for contributions, and translating existing (old API)
testcases, examples and documentation to 'new API' would definitively be
a good starting point, but be aware that even if done correctly, the
code could not yet possibly work.

-- 
Silvio Clécio

reply via email to

[Prev in Thread] Current Thread [Next in Thread]