[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] Connection not represented by a file descriptor
From: |
Christian Grothoff |
Subject: |
Re: [libmicrohttpd] Connection not represented by a file descriptor |
Date: |
Wed, 16 Jul 2014 11:58:00 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 |
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
>
>