This assessment may even be conservative. Considering that you're going to be making these generic pieces try to work together in a matter that doesn't break,
In response to "doesn't break": What I would stress for instance is take databases as an example. There are ways to interface to databases with out knowing how the underlying database is implemented such as ODBC. I am not saying to implement an entire database with the exception of a simple file based database as the default - to allow nubies/learners/Stroustrup's students a quick and easy way to learn databases, GUIs, etc . What I am getting at here is to provide front end interfaces to back end service providers such as database solution providers. We define the interface and they hook up their database to the back end interface. I am sure we all do not want to spend our time writing databases, but what we can do is provide a standard interface in C++ to these databases. If "it breaks" then it is a result of: 1) Interface not providing the necessary abstraction 2) database provider not implementing the interface correctly. I know for performance applications this may be a gross oversimplification
then you've got yourself a very large scale project that although a lot of people want, not a lot of people have the time/resources/motivation to write.
I am willing to dedicate my time so that I myself and others don't have to waste theirs. Think of the problems we could solve as a society if we were not wasting our time learning obscure interfaces to databases and GUIs. My efforts may not end in a final solution, but merely tow the rope until the next stage of development. Time will tell. I know how painful this is. I think the first step (which is under way
IIRC) is to develop a common base for everything network-related in C++ -- this I think is what Asio gives, and is already being considered to be made part of the next version of the C++ standard. That being said, what we have now are the building blocks to be able to come up with more specific targetted tools.
I understand the evolution process of C++/boost... believe me.. and as you have noted we are now just getting the finite quantum of core libraries to attempt these endeavors.
Having said this, I don't necessarily think this should be made part of Boost. Anybody should be able to come up with their own Web Services framework in C++ and license it under the Boost Software License without having to be part of the Boost C++ Library.
I will never and do not want to put restrictions on the development efforts of others. My goal here is to provide standard interfaces to those software implementations. This would require software churn on the part of say a data base developer to "hook-up" to the boost standard interface. The user could choose which to use the standard interface or the direct API. The ultimate goal to to flush out standard interfaces/libraries then push them to C++ standard libraries or maybe by that time we will have the concept of packages.
WRT to Databases, have you seen SOCI?
Nope, but I remember talking to a gentleman at BoostCon on the way back from lunch. He mentioned it, but I skipped my mind to look it up before I got back. Thanks for reminding me about it!!! http://soci.sourceforge.net/ Yes this is the kind of interface I am talking about standardizing. http://soci.sourceforge.net/doc/structure.html What I wish to standardize is the "C++ syntax and core libraries" and "common backed Interface". Maybe SOCI developers would consider boostifying the interface. I have looked at the code to the database implementation checked into boost vault that Nicola Musatti wrote up. I need to contact him to see what his plans are for this latest version states 2007. It doesn't compile in 1_35_0 which is not surprising based on the version dates. I will try it with vintage versions of boost. Databases are an easier concept to provide this architecture. For GUIs is is much more difficult to abstract away the interfaces especially when the desire is to take advantage of existing libs such as QT, KDE, GNome, GTK, WxWidgits, FLTK, etc. Especially when you consider that the libs support much more than just UI libraries (such as XML) and all do not (some do) have C++ interfaces. XML Stream parsing is something that's fit for the Iostreams lib along
with Asio underneath -- very important for XMPP and other streamed XML protocols -- but I have very little experience with XML Stream parsing and Iostreams to be able to give a better idea about it. But it does sound natural to map stream-based protocols to the Iostreams interface.
Here I am not sure that streams would have to be used for XML, unless boost developers want to tackle a XML parser SAX2 and DOM, Compliant to W3C specs, as existing libs already exist such as xerces, libxml etc, but rather a common interface to bridge to C++. These libs take care of the parsing, we would take care of the standard interface to C++. I am sure readers of this would ask the question, as I am myself : if your going to create a standard interface to libraires for something like xml why not just write a full parser and not worry about standardizing a frontend/backend interface. My opinion here is for something like XML this may be possible, for databases and GUIs I do not believe it to be (though abstracting away the interfaces is no small task - especially if interoperability between different UI implemntations with a common front end interface is desired.).
Right. I think also the goal of Boost is to be a place for developing software/libraries not just for general use, but also for eventual standardization. Already, libraries like Regex, Thread, Tuple, and (IIRC) Asio are going to be part of the next version of the standard.
Yes these are good times to be a C++ programmer!!!
Actually, the interface and implementation will change -- and is currently being developed (by me) offline, and at a snail-steady pace. The idea is that whether you use SSL or plain TCP, it will use Asio underneath. There will be two client implementations: a synchronous one, templated to whether you use SSL or use a proxy, etc.; and an asynchronous one, supporting pipelining and "automatic session management"
Curious on your automatic session management. What ideas/features to you have here?
with cookie and (eventual) caching support -- all while trying to be a header-only implementation.
Sweet.
The message framework that's already there allows for building opaque messages, and a transformation layer is provided to support conversions from one message type to another either through library implemented routines or through user-generated functions. That allows you to:
1. Create a soap::message implementation that converts to an http::message or an xmpp::message (whichever you support)
An then SOAP to RPC...??? Which brings up another missing lib (RPC) in boost.and then there was this post: http://lists.boost.org/Archives/boost/2005/03/81179.php namespace IMO { Which is frankly not true. I could use it right now. And I am not talking a CORBA interface. I have no desire in my current work to have C++ talking to COBOL or JavaScript just C2C. At least Java has RMI. And this: http://lists.boost.org/Archives/boost/2005/03/81169.php 101 votes with a 4.66 rating out of 5 for the RMI for C++ article ... so someone's interested in this. Ah yes macros... oh the horror. I have seen implementations where there is a 2+ page macro wrapping a class instance in an attempt at RPC using boost with serialization and asio. Variadic templates would greatly help simplify an RPC library available in GCC 4.3 and 4.4, MSVC 2008? Hmmm I should try this with GCC. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2555.pdf } // namespace IMO
2. Have that object instance passed to a client that talks the appropriate protocol 3. Get a generic protocol::message response 4. Convert to the appropriate (in this case soap::message) type for further processing.
This allows me to write an HTTP(S) client without having to think about all the possible messages that come through and only support one kind and work well with it.
The message framework is already done, and help with testing and further development would be greatly appreciated. :)
I am currently spending my time on Dataflow and I need to boostify my Data Binding example, but let me know what I could do. I already have the code checked out. Currently I can build for MSVC 8, MSys, Cygwin, Ubuntu Linux, and Gentoo. I did try to get cpp-netlib to compile in mingw and msvc 8. It did not. Are you using trunk of boost or 1.35.0? I am attempting building the trunk of netlib. -- Brian