Re: [boost] web service client based on boost?

From: Brian Davis (bitminer_at_[hidden])
Date: 2008-08-09 02:46:40

> 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