[boost] Re: RPC library

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-03-01 16:54:41

Jarl Lindrud wrote:
> Jonathan Turkanis <technews <at> kangaroologic.com> writes:
>
>>
>> I'd like to make underlying transport mechanism pluggable, so people
>> can implement other IPC mechanisms.
>>
>> BTW, don't tell anyone, but I'm implementing OpenSSL wrappers for
>> the iostreams library, which might be used for the socket interface.
>>
>
> I'm working on factoring out the transport mechanism, mainly because
> I want to be able to use asynchronous networking (I/O completion
> ports on Windows). iostreams don't mesh too well with async i/o
> though, so I'm not sure that that's the best place for the SSL stage,

Unfortunately, "iostreams" is not really the best name for the iostreams
library. "io" would have been better, but it was already taken.

The devices provided by the iostreams library, such as memory mapped files, can
be used independently of std C++ iostreams, which as you say don't work too well
with non-blocking or async i/o.

The first version of iostreams will support non-blocking i/o. I'm planning to
introduce asynchronous device concepts at some point, but haven't done so yet.

> I'd rather have it bound up with the transport mechanism.

Okay.

> I've found
> it more practical to keep the transport completely separate from any
> iostreams; once a chunk of data has arrived, just construct a
> stringstream on top of it.

>> One last point is that Boost.Interfaces is not as portable as your
>> current implementation. For example, it works on GCC 3.4 but not GCC
>> 3.2. When the design is finished I will work on porting it to some
>> currently unsupported platforms, but there are limits: it will never
>> work on Borland 5.x, for instance.

> But then Borland 5.x is a seriously bugridden compiler.... 95% of my
> porting problems were with that compiler. :)

Tell me about it!! ;-)

> Jarl.

Jonathan