Re: [boost] asio formal review - portability

From: Darryl Green (darryl.green_at_[hidden])
Date: 2005-12-31 08:57:49

Christopher Kohlhoff wrote:
> I do appreciate where you're coming from, but I think we must
> have fundamentally different design philosophies in mind.
> 
> To summarise my understanding of it, you want to be able to
> leverage commonality of implementation on the platforms that you
> target, and compose policies to influence how the abstractions,
> such as stream_socket, behave.

I don't want to change the behavior of anything. I want to map some 
concepts into policies, properly define them and have lots of impls all 
with the same behavior.  I see that you didn't respond to any of my 
specific examples of other I/O channels or the breakdown of  "what I 
would like to see". Do you intend to implement every form of I/O, 
including message-based and stream-based IPC, disk, character devices 
and the ever-growing plethora of networking protocols (I see someone 
else has mentioned SCTP already) that can be done asynchronously? I 
realize that it would be unusual for anyone to need all of them, but 
someone needs each of them - I was hoping that the library could be 
opened up to those someones to extend without creating a maintenance 
nightmare.

> With asio, the public interface instead says nothing about
> commonality of implementation, since such commonality cannot be
> portably assumed.

Fine. I'm not suggesting you can or should require it - I am suggesting 
that if the design was tweaked slightly, it would be possible for the 
user/extender (or the maintainer/author) to re-use impl when it can be 
re-used.

> The implementation detail can make use of such
> commonality, certainly. For the user of asio, commonality is
> provided through implementation of concepts, such as the Stream
> concept implemented by stream_socket and ssl::stream.

Yes. I want to make public impls of the concepts in a more flexible way.

> 
> I am not averse to compile time or runtime tweaks to alter
> implementation behaviour. Or, dare I say, completely different
> implementations of the public interface that provide alternative
> QoS characteristics.

Huh? I'm utterly confused. I guess you must be too - sorry I'm obviously 
doing such an atrocious job of describing what I'm after. I split up my 
replies to try to focus the discussion better and avoid confusion but 
obviously I've failed.

> But ultimately I am not in favour of the sort of framework that
> allows endlessly customisable behaviour via policy composition
> for a library such as this. Of the programmers developing
> networking code, I imagine that very few have both the skills
> and inclination to make use of this level of customisation in

If the library just magically supports every form of IO on a platform 
out of the box, with the choice of I/O mechanism being largely 
transparent to higher-level code, then there will be no need for 
customization. I don't think that is a realistic requirement.

> source code. Besides, the more combinations, the greater the
> chance of something going wrong, and the less time I can spend
> testing each one!

The testing and maintenance angle is one of my major motivations for 
proposing this. If you have umpteen different forms of I/O all of which 
use the same readiness notification mechanism and require the same 
processing to actually do an async read/write why would you want to 
implement and maintain and test umpteen separate user accessible 
services for read/write rather than testing that your shared read/write 
impl in depth and the aspects of those various forms of I/O that are 
unique such as the way that the channel is opened separately?

I'm guessing that you wouldn't actually chose to duplicate code and you 
would use shared code in detail to avoid it. I'm suggesting that with 
care the shared code can align with concepts/policies and, once it is 
(meaning it has a defined interface and semantics) it can be made 
public. Thats all. If nothing else this makes the testing scale better 
without having tests rely on non-public interfaces.

The other aspect of testing is that nobody can be expected to test code 
that isn't in the lib - if a user extends the library and either doesn't 
contribute the code or it isn't accepted into the lib there is nothing 
extra to test? I'm not asking for a lot of weird mix-and-match policies 
- just a few to compose the sorts of services that the lib should (imho) 
support anyway, but in a user configurable way.

> The number of permutations allowed by such a policy-driven
> interface would be a barrier to what I believe is a more
> important goal: the development of portable, reusable,
> higher-level abstractions.

I see the ability to adapt the library while preserving a consistent 
interface to be a necessity to support higher-level abstractions.

Regards
Darryl.

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/217 - Release Date: 30/12/2005