Re: [libmicrohttpd] Connection not represented by a file descriptor

[Christian Grothoff]

Hi!

Well, I personally don't know how useful this would be for
anyone else, so I was waiting to see if anyone else would
advocate for this.

Also, of course it is hard to judge if a patch might be
acceptable without having seen it.  Overall, I'm a bit
sceptical about the benefit/complexity trade-off, but
mostly I wanted to wait and see if there was any discussion
on this to convince me either way.

Seeing a concrete patch might of course lead to a more
informed discussion...


happy hacking!

Christian


On 07/16/14 11:48, Tomas Heran wrote:
> Hello,
> 
> this is just a polite reminder that I'd really like to get your opinion
> on implementing connections like I described below.
> 
> Thanks you,
> Tomas
> 
> On 04 Jul 2014, at 16:25, Tomas Heran <address@hidden> wrote:
> 
>> Hello.
>>
>> I've recently started evaluating libmicrohttpd for purposes of my
>> project and while I like very much what I've seen so far there are
>> specific requirements imposed by my execution environment which
>> make integrating MHD HTTP server a little challenging.
>>
>> Namely:
>>
>> - The program handles its connections independently from MHD (listening,
>>  accepting new client connections and spawning threads to handle the
>>  client connections, etc.)
>>
>> - The connections are presented to the rest of the program as
>>  "objects", i.e. structures containing file descriptors which
>>  are not accessible from the client handling code (furthermore,
>>  even if the low-level fds were accessible, they aren't always
>>  sockets)
>>
>> If I eventually decided to use MHD for my project, I'd have to
>> introduce to MHD a special kind of connection that is represented by a
>> set of functions for reading, writing, selecting/polling, closing etc.
>> and an "ID" to be able to find the particular "stream" that the
>> functions need to operate on.
>>
>> While understanding this may be very specific to my project and not too
>> interesting for many others, I'd still like to know whether you'd be
>> interested in accepting a patch that implements such kind of
>> connections? My intention would be to work with the community to
>> introduce a suitably generic/abstract representation that would
>> maximize re-use for other similar use cases.
>>
>> Please let me know.
>>
>> Thank you,
>> Tomas Heran
> 
>