Re: [boost] Re: behond IOStreams

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-09-12 17:49:49

On Mon, 13 Sep 2004 00:13:44 +0200, Carlo Wood wrote
> On Sun, Sep 12, 2004 at 02:31:17PM -0700, Jeff Garland wrote:
> > would encourage you to help on boost.socket et. al.
> 
> Are you the author of boost.socket?  I mailed to the email
> address given on sourceforge (the giallo project) but got
> no response.  I assumed the project was dead.

No, but I helped with some concept development and contributed ideas.  Hugo
Duncan was the lead developer -- he moved it off to giallo in April of this
year.  I never really understood why....

> > Honestly, I think there
> > isn't much overlap between boost.socket and IOStreams.  In previous
> > discussion,  we hashed around the idea of having a streambuf and stream to use
> > with sockets -- it's been so long since I looked at it I'm not sure what if
> > anything got implemented.
> 
> I am interested in designing a standalone multiplexor library.
> It should merely *support* IOStream - it should be possible to
> use the two together in a seemless way.  The multiplexor library
> itself however is not really related to streambufs imho.
>
> > Also, if it's just multiplexing then there were a few ideas we discussed --
> > again I don't think there's implementation of all these things yet.
> > 
> >
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/Multiplexing
> 
> Yes I already read that.

Good.  I don't think that the discussion is at it's end there.  Boris put
together the idea -- obviously the discussion there is very network
programming centric and then things kind of sputtered out.  

So if you are thinking of multiplexing you must have other things in mind,
like timers, signals, etc?  Anyway, I can see that  perhaps there can be a
multiplexing core that can have other elements added as they are developed.

As for the I/O piece it seems to me that the relationship with the buffer and
not the stream.  The stream is there for formatting and the buffer is there
for data management.  To handle async I/O and such it seems to me that the
buffer needs to be enhanced -- the stream can be as well, but foundationally
the resposibility has to start in the buffer.
 
> Did you read my previous posts?  Please do so.  Have a look at point 
> 5. Please reply to point 1 through 6 in that order (and only post in 
> a next thread when you basically agree with the previous thread).

Probably not...
 
> > I still want to see a modern replacement adopted into boost, but you have
> > figure it would be at least a year out -- assuming someone was really working
> > on it :-(
> 
> I am about 20 times faster than most people (according to my boss) :)
> On the other hand - I think I'll need 2 months for the code - and another
> 1 or 2 months for documentation and examples, because I am not familiar
> with windows (yet) (if it were only unix then 365/20 = 18 days would 
> indeed be more than enough).

Yeah, I didn't mean that it would be a year of development.  I meant it would
be a year b/f it could be in boost with reviews and such...

> However - lots and lots and lots of time will be spend on waiting for
> people to reply to posts - and RE-post the same things over and over
> because they don't read things very well :p.  I am not sure yet if I 
> will have the patience for that :/ - we'll see how that goes.  I had 
> the plan to wait with further development till several people had 
> replied the 6 threads that I started - but after 24 hours still no 
> real reply has been posted, and not doing anything for more than a 
> day is not acceptable. I guess I will have to continue without 
> feedback then :(.

You might not get immediate replies -- especially on a weekend.  And double
especially on Sept 11.

> Unfortunately - additional posts (like a point 7, 8 etc. do make 
> sense without feedback - because they would be 'fuzzy' brainstorm 
> things, lots of feedback back and forward with a very small delay 
> will be necessary to make any progress imho.  Perhaps, if you are 
> the author of boost.socket, we should do this in a private mail exchange?

I'm willing to discuss it offline.  That's often how the most progress is made
on new libraries...

Jeff