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/M...
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