|
Boost : |
From: x.lsi.maillard_at_[hidden]
Date: 2001-12-25 17:53:05
THIS IS AN AUTOMATICALLY GENERATED REPLY
Your mail to me has been discarded
Hi! You have reached the mail filter of one Richard Gooch. I'm sorry
to have to do this to you, but I am now filtering my email to combat
the flood of junk email (spam) that I receive. I'm fed up with having
to waste my time sifting through junk email. This filter also protects
me from certain types of mailbombing attacks.
I received an email from you, but my mail filter doesn't think you
sent it to me personally. This may be because I am on some mailing
list I'm not aware of. It may also have come from a mailing list I
*am* subscribed to, but the list adminstrators have started fiddling
with (breaking) the listserver.
APOLOGIES if the mailing list is genuine (i.e. not a spam list). If
you receive this reply because of a message you sent to a genuine
mailing list, please send me a message (telling me which mailing list
I'm on) with the following in the subject line:
293977
This is my password of the week. My mail filter will then let me see
the message. NOTE: the password MUST be in the subject, not the body.
I will then add a rule for the mailing list (or unsubscribe myself if
I don't wish to be subscribed) so that this won't happen again. I
apologise to people subscribed to mailing lists if this message is
sent to the whole list; I have taken considerable care to make sure
that mailing lists I want to be subscribed to are not affected by my
spam filter.
NOTE TO BULK EMAIL ADVERTISERS, SPAMMERS AND OTHER PARASITES: if you
manage to break through my filtering, rest assured that I will ignore
your message on principle. Future mails will be automatically deleted.
Unsolicited commercial email is unwelcome and costs *me* time to deal
with.
The message you apparently sent to me follows:
>From fxgs Tue Dec 25 23:53:04 2001
Return-Path: <sentto-1234907-19298-1009158147-x.lsi.maillard=wanadoo.fr_at_[hidden]>
Delivered-To: fxgs_at_localhost.hometranet.home
Received: from 192.168.1.2 [192.168.1.2]
by localhost with POP3 (fetchmail-5.9.0)
for fxgs_at_localhost (single-drop); Tue, 25 Dec 2001 23:53:04 +0100 (CET)
Received: from localhost (localhost.localdomain [127.0.0.1])
by mail.hometranet.home (Postfix) with ESMTP id B97362B075
for <fxgs_at_localhost>; Tue, 25 Dec 2001 18:49:47 -0500 (EST)
Received: from pop.wanadoo.fr
by localhost with POP3 (fetchmail-5.7.4)
for fxgs_at_localhost (single-drop); Tue, 25 Dec 2001 18:49:47 -0500 (EST)
Received: from mel-rti17.wanadoo.fr (192.168.156.136) by ms4-2.wanadoo.fr; 24 Dec 2001 02:42:30 +0100
Received: from n21.groups.yahoo.com (216.115.96.71) by mel-rti17.wanadoo.fr; 24 Dec 2001 02:42:29 +0100
X-eGroups-Return: sentto-1234907-19298-1009158147-x.lsi.maillard=wanadoo.fr_at_[hidden]
Received: from [216.115.97.191] by n21.groups.yahoo.com with NNFMP; 24 Dec 2001 01:34:38 -0000
X-Sender: green_at_[hidden]
X-Apparently-To: boost_at_[hidden]
Received: (EGP: mail-8_0_1_3); 24 Dec 2001 01:42:20 -0000
Received: (qmail 77634 invoked from network); 24 Dec 2001 01:42:20 -0000
Received: from unknown (216.115.97.172)
by m5.grp.snv.yahoo.com with QMQP; 24 Dec 2001 01:42:20 -0000
Received: from unknown (HELO gatewaya.tabq.com.au) (203.3.76.4)
by mta2.grp.snv.yahoo.com with SMTP; 24 Dec 2001 01:42:20 -0000
Received: from no.name.available by gatewaya.tabq.com.au
via smtpd (for mta2.grp.snv.yahoo.com [216.115.97.172]) with SMTP; 24 Dec 2001 01:42:19 UT
Received: by wntx.tabq.com with Internet Mail Service (5.5.2653.19)
id <YNPT46GH>; Mon, 24 Dec 2001 11:42:17 +1000
Message-ID: <696BA06B3A0FD211BAAD0060B0C4DD8301FD3D1A_at_[hidden]>
To: "'boost_at_[hidden]'" <boost_at_[hidden]>
X-Mailer: Internet Mail Service (5.5.2653.19)
From: Darryl Green <green_at_[hidden]>
X-Yahoo-Profile: d_r_green
MIME-Version: 1.0
Mailing-List: list boost_at_[hidden]; contact boost-owner_at_[hidden]
Delivered-To: mailing list boost_at_[hidden]
Precedence: bulk
List-Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
Date: Mon, 24 Dec 2001 11:42:16 +1000
Subject: RE: [boost] Re: sockets library
Reply-To: boost_at_[hidden]
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Status: O
> From: bill_kempf [mailto:williamkempf_at_[hidden]]
> Sent: Saturday, 22 December 2001 2:10 AM
> --- In boost_at_y..., Darryl Green <green_at_t...> wrote:
> > <rant>
> > There are LOTS OF platforms in existance that are not win32, un*x
> or mac and
> > do have BSD socket style networking.
>
> Yes, and your point is?
My point is that there was much discussion of efficiency, protocols, usage
etc. that were somewhat coloured by (among other things) the platform. My
point was not very well made. Perhaps I should have just said;
"most" in the requirements for a library won't cut it - the library needs to
be designed with the intent of supporting "all" - and I don't mean by making
it a single huge monster.
>
> > There are environments in which using iostreams is BANNED and where
> using
> > sockets certainly isn't.
> Banned?
Yes.
> Why and which environments?
In the environments in question iostreams have cost a lot in terms of code
size and performance while giving very little back in the way of
functionality. This is partly a library design and partly a library
implementation problem imho - I gather that Dinkumware (and others?) have
managed to address this, but the easy way out was just to avoid the whole
thing. This hasn't caused us much/any pain - though obviously there are
problems when trying to use other libraries that in turn use iostreams...
> Embedded?
Yes.
The reasons why
> iostreams are avoided there (I don't like the term banned) probably
> won't apply to a binary_iostream.
Yes. Agreed.
>
> > There are protocols that are not designed so humans can read them,
> but are
> > designed so the data will fit (either a lot of data, or a small
> pipe) and/or
> > be efficently processed at each end.
>
> Yes, and that's what a binary_stream will allow you to do.
Good.
>
> > There are protocols that have some truly exotic and complex internal
> > structure that no amount of iostream handling is going to help
> with. Well -
> > ok - I guess someone could build some interesting magic for
> formatting data
> > as (say) ASN.1 via iostreams, but I'm not volunteering.
>
> This shouldn't be too difficult to do. I don't believe it will
> require any "interesting magic", either.
Depends what you want it to do exactly. Do you think it would be simple to
build something that would replace the functionality of SNACC and Agent++
for a start? I've thought about doing this and pragmatism (read deadlines)
has won the day. Maybe I need to think about this some more, but for complex
types I don't see fitting this sort of stuff into an iostreams view of
things being helpful/possible?
>
> > KISS.
>
> YES!
>
> Start with a few basics, such as a socket class and a network_name
> class. From this build some higher level abstractions: a socketbuf,
> socket_stream and binary_socket_stream (first requires a full
> binary_stream library). From these (or maybe from the lower level
> socket class, though you'll lose a lot of very useful functionality
> if you do this) you build even higher level abstractions along the
> lines of what Jeremy's suggested. Build things in layers, keeping
> each layer as simple as possible.
Yes. Precisely. My only real concern was that there might have been a
restriction on what/how higher level protocols and other abstractions could
be built (efficiently) without getting back down to the level of a trivial
wrapper around the standard sockets api. This could happen if machinery to
support "most" protocols sneaked in at too low a level. You and others have
convinced me that using streambuf is not going to introduce this problem.
Please consider my objections withdrawn.
>
> Bill Kempf
>
>
> Info: http://www.boost.org Send unsubscribe requests to:
<mailto:boost-unsubscribe_at_[hidden]>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Info: http://www.boost.org Send unsubscribe requests to: <mailto:boost-unsubscribe_at_[hidden]>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk