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

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-08-09 06:32:04

Hi Brian,

On Sat, Aug 9, 2008 at 2:46 PM, Brian Davis <bitminer_at_[hidden]> wrote:
>> 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
>

True. This I think is how Python does it with the standard library
interfaces to DB's are concerned. If you want your DB client to be
easily usable in the Python arena, you'd have to abide by the DB Api.

Although this has worked with other dynamic languages (that rely
heavily on runtime dispatching, and lot and lots of runtime
abstraction), making it work with C++ is a little finicky at best:
having no standard ABI for example is a problem. The motivation then
towards static polymorphism and compile-time dynamic programming
(template metaprogramming, leveraging the type system to do dispatch)
becomes more evident and at time more robust than relying on RTTI and
the run-time in general.

That being said, for *any* interface development to work correctly, it
has to be distilled from a pool of existing common implementations,
rather than developed in isolation of existing solutions. Asking
someone (a vendor for example) to conform to a pre-defined API sounds
a little wrong to me.

[snip]
>
>> 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.
>

I've made it work successfully with Boost 1.35. If you can bring up
your concerns to the SOCI-users list, then that would be a good start.

As far as standardizing, I think the people involved with SOCI have
voiced their thought about not making it part of Boost, but rather
making it work well with Boost instead. I forget if it's on this
mailing list or in the SOCI-users mailing list.

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

I don't have much experience with GUI's, but I think standardizing
interfaces has to be a process of evolution rather than an end on
itself. I believe the Python DB API came about from distilling the
myriad of implementations to different DB backends and coming up with
a framework to abstract the details of underlying implementations.
This is what SOCI has done (very well I might add) that is worth
emulating for developing web service clients (XML-RPC, SOAP/HTTP,
REST, SOAP/XMPP, CORBA, etc.).

That's again, easier said than done, but it has to be an abstraction
layer that makes sense and is expressive enough to actually use and
implement.

You might want to look at how Boost.MPI (and the MPI standard in
general) has been developed to standardize the message passing
interface among the myriad implementations available out there.
Ultimately the vendors agreed to a set of standard API's that they all
will support. Key to this is the fact that they already had their own
implementations and they simply got together and agreed on a common
sub/super-set of interfaces they will implement.

> 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, but ultimately you need the underlying pieces to be able to
make the pieces work together. And in making these pieces (XML
parsers, dom representations, transformation engines, etc.) work on
their own in an orthogonal fashion makes it a lot harder effort.
[snip]
>
>> 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 HTTP 1.1, there's support for persistent connections on the
server side. If the server side supports it as well as pipelining,
then the client will be implemented to take these into consideration.
The connection management becomes the domain of the client, and
therefore clever implementations like request pipelining and even
persistent connections would be leveraged for you.

>
>> with cookie and (eventual) caching support -- all while
>> trying to be a header-only implementation.
>>
>
> Sweet.
>

Indeed. We're adapting parts of the HTTP implementation of the
libpion-net library specifically the cookie management and
encoding/decoding solutions to be made part of the cpp-netlib project.

[snip]
>>
>> 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.
>

I've been working on the http_integration branch and only just
recently (as in yesterday) I've revamped the implementation of the
HTTP client to make use of lower level Asio primitives instead of the
higher level stream implementation. We've been building/testing
against Boost's trunk and Boost 1.35.0.

Nobody has had success building cpp-netlib's tests for mingw. For msvc
8, we've only recently been able to test with Boost.Jam+Boost.Build --
there are no MSVC-specific build packages/solutions/projects yet,
since bjam works fine for us. If you would like to help out in that
effort, please join us in the mailing lists. See
http://sourceforge.net/projects/cpp-netlib for details. :)

HTH

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.