Hi Frank,
----- Original Message -----
>
> ...
> I propose not enabling the gnutls SSL stuff in libmicrohttpd, until
> at
> some point we undertake a port to nss directly (which we could send
> upstream), or through the recently-added posix-socket-io layer in
> libpcp (which we could not upstream).
OK, sounds like a plan. My quick scan through the libmicrohttpd
suggested it will be a non-trivial undertaking to make it NSS/NSPR
aware (like with the rest of PCP), so would need a very supportive
upstream or a local fork. Either works for me, its clearly such a
oft-requested feature that we need to take on its maintenance as a
core PCP component in one form or the other. Happily there's also
an extensive set of tests in the libmicrohttpd sources.
> > ...
> > Step 2 seems to be amenable to being extracted into a library
> > that could be shared. [...]
>
> I must admit I don't see that much potential in this. How about we
> leave refactoring till there is more than one ... product?
>
Sure. I was thinking of a production environment I've been involved
with in the past, and they in particular could have used this (with a
java API) to remove a bunch of old code. The idea of a demo as clear
and simple as the Flask one appeals too, so at some point I hope to
take a crack at this abstraction. Definitely an optional-extra though.
> > [...] Oh wait - one final thought - for the daemon, the name
> > "pmwebapi" doesn't seem to roll off the tongue - how would you feel
> > about a "pmwebd" and perhaps a libpcp_webapi.so / <pcp/webapi.h>?
>
> How about just rename to pmwebd, but not bother with libs/headers at
> this time?
*nod* - fine with me, thanks.
cheers.
--
Nathan
|