From: Chris Fairles (chris.fairles_at_[hidden])
Date: 2007-12-09 23:18:54
I found pion the other day, I used the scheduler and connection idea
(stripped down, non-camel case) for an irc client lib (in the works).
You can find the code here: http://skotty.coffeebuzzin.com/browser/trunk
I've been looking for some help and guidance on making a "boost.irc"
similar to this http (and boost.net) idea. Currently the message
parser relies on boost.spirit (implements the EBNF almost verbatim
from the RFC) and I only have client-components implemented. Server
will be next.
I also have some FTP stuff: http://sourceforge.net/projects/bftp but
haven't had time to make it complete and generic. It's just a basic
client again, no server components.
I'll try to keep up to date on this, quite busy but maybe some of this
code can be of some use.
On Dec 9, 2007 10:09 PM, Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
> On Dec 10, 2007 10:43 AM, Jeff Garland <jeff_at_[hidden]> wrote:
> > Dean Michael Berris wrote:
> > > Hi Jeff!
> > >
> > > On Dec 10, 2007 10:32 AM, Jeff Garland <jeff_at_[hidden]> wrote:
> > >> Michael Dickey wrote:
> > >> >
> > >>> So.. I decided to throw all this out there and see what people think.
> > >>> Should Boost have its own HTTP library, or should it be part of an
> > >>> more comprehensive network protocol library?
> > >> Yes, it should have an HTTP library -- it would be nice if there were other
> > >> protocols, but not essential.
> > >>
> > >
> > > I have the same feeling, but then other protocols are becoming
> > > increasingly more and more important as the web matures -- XMPP is
> > > lurking to be the next generation IM/Messaging protocol, (E)SMTP is
> > > not going away for Email anytime soon, and FTP is still very popular.
> > > Maybe having a torrent client library might not be essential, though
> > > if there's enough interest then it may just be the next generation
> > > fail-safe P2P storage protocol -- or I might be dreaming too much. ;)
> > I didn't mean to 'dis' the importance of the other protocols. What I meant to
> > say is that if we try to bring an entire suite as one library, in one review,
> > it will a) take a long time, and b) be hard to manage. So I'd rather see them
> > come as smaller contributions -- perhaps within a shared framework boost::net
> > or whatever.
> Ah, yes. Now that makes sense to me.
> As to doing it by piece meal (HTTP first, then SMTP next perhaps)
> maybe we'd get more mileage. :)
> > >
> > > If Mike already has an HTTP client library we can retro-fit to work
> > > with the cpp-netlib basic_message<> implementation, then I think we
> > > don't have to re-invent the wheel as far as an HTTP client
> > > implementation goes -- and cpp-netlib 1.0 might just be around the
> > > corner once we document it properly and get it tested up to Boost
> > > standards.
> > Looks to me like Mike is focused on the server side...so maybe there's not
> > much overlap anyway.
> Too bad... That doesn't change though, cpp-netlib will be focused on
> the client side. Insights from the libpion implementation may help
> though, especially with HTTP 1.0/1.1 implementation details.
> Dean Michael C. Berris
> Software Engineer, Friendster, Inc.
> [+63 928 7291459]
> [+1 408 4049523]
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk