Curl wrapper

[Masahiro Nakagawa]

On Tue, 24 May 2011 04:50:10 +0900, jdrewsen <jdrewsen at nospam.com> wrote:

> Den 23-05-2011 21:02, Masahiro Nakagawa skrev:
>> On Wed, 18 May 2011 20:07:01 +0900, Jonas Drewsen <jdrewsen at nospam.com>
>> wrote:
>>
>>> On 18/05/11 10.09, Johannes Pfau wrote:
>>>> jdrewsen wrote:
>>>>>
>>>>> But I would rather stop here feature wise and wrap
>>>>> this thing up. I would like to focus my efforts on a candidate for
>>>>> std.net.event/reactor/proactor module.
>>>>
>>>> Have you already started working on std.net.event? Do you plan to base
>>>> that on libev / libevent?
>>>
>>> I'll finish the curl wrapper before starting on it.
>>>
>>> I have had a look at libev/event before and they are very nice libs.
>>> But I think I'll have to implement it from scratch for two reasons:
>>>
>>> 1, AFAIK we cannot include code in std phobos that is not boost
>>> licensed or a license as liberal. libev for example requires you to
>>> distribute the license with your software.
>>>
>>> 2, It introduces a dependency to an external project in phobos.
>>> Currently no dependencies are present. This makes phobos very easy to
>>> install and use out of the box.
>>>
>>> The optimal solution to these problems from my point of view would be
>>> to get that "much discussed" package tool in place soon (CPAN,apt  
>>> alike).
>>>
>>> Heck, now I think about it maybe I should do that before any std.net
>>> stuff. Let's see how the wind blows - many interesting projects :)
>>
>> Good!
>>
>> Last year, I tried to implement std.event. In Windows, using IOCP with
>> Overlapped-IO for proactor.
>> Others, IO multiplexing with worker-thread for proactor emulation.
>> But Johannes already started implementing event module using libev,
>> so I deleted this task from my tasks.
>>
>
> If you have any code for inspiration or that could be used as a base I
> would very much like to see/use it. Especially if it is under Boost  
> license.

My old design is based on Boost/Asio. After I rewrote std.socket(including
other utilities such as DNS, IPAddresses), I stopped implementing task.

> I would like to create reactor initially and proceed to build the
> proactor on top of that (not on top for windows and IOCP of course).
> Reactor and proactor designs each have their forces and therefore I do
> not think targeting a proactor only design is the way to go.

I agree. General library should provides two approaches.
My main purpose is high-performance RPC. In such cases,
Proactor is better(Java's Netty provides good abstraction APIs).