diff --git a/index.html b/index.html
new file mode 100644
index 000000000..2cac53c9b
--- /dev/null
+++ b/index.html
@@ -0,0 +1,25 @@
+
+
+
+
+
+
+
+
+
+
+
+ Automatic redirection failed, please go to index.html.
+
+
+
+
diff --git a/libs/network/doc/architecture.qbk b/libs/network/doc/architecture.qbk
index d43eeb565..dbf417258 100644
--- a/libs/network/doc/architecture.qbk
+++ b/libs/network/doc/architecture.qbk
@@ -7,11 +7,19 @@
[section:architecture Architecture]
-__cnl__ is built upon __boost_asio__, a high-quality, portable asynchronous I/O library that provides a solid interface for C++ network programming.
+__cnl__ is built upon __boost_asio__, a high-quality, portable
+asynchronous I/O library that provides a solid interface for C++
+network programming.
-The architecture is driven by the requirement to separate requests and responses from the transport mechanism. Additionally, it utilises generic programming techniques to make decisions at compile-time, resulting in more efficient and stable client code.
+The architecture is driven by the requirement to separate requests and
+responses from the transport mechanism. Additionally, it utilises
+generic programming techniques to make decisions at compile-time,
+resulting in more efficient and stable client code.
-There are two main features of the architecture which use modern C++ techniques to allow extensibility without comprimising efficiency: tags and directives. It is these techniques that underpin the design of the message.
+There are two main features of the architecture which use modern C++
+techniques to allow extensibility without comprimising efficiency:
+tags and directives. It is these techniques that underpin the design
+of the message.
[include message.qbk]
[include uri.qbk]
diff --git a/libs/network/doc/html/c___network_library/acknowledgements.html b/libs/network/doc/html/c___network_library/acknowledgements.html
new file mode 100644
index 000000000..5e68c3a6e
--- /dev/null
+++ b/libs/network/doc/html/c___network_library/acknowledgements.html
@@ -0,0 +1,46 @@
+
+
+
+Acknowledgements
+
+
+
+
+
+
+
+
+ C++ Network Library is built upon Boost.Asio,
+ a high-quality, portable asynchronous I/O library that provides a solid interface
+ for C++ network programming.
+
+
+ The architecture is driven by the requirement to separate requests and responses
+ from the transport mechanism. Additionally, it utilises generic programming
+ techniques to make decisions at compile-time, resulting in more efficient and
+ stable client code.
+
+
+ There are two main features of the architecture which use modern C++ techniques
+ to allow extensibility without comprimising efficiency: tags and directives.
+ It is these techniques that underpin the design of the message.
+
+ The initial concept behind the C++ Network Library is the basic_message
+ template. The advantage of this is that basic_message
+ can be specialized for different protocol implementations.
+
Defines the underlying string type, so that the message can be specialized
+ for different text encodings
+
+
+
+
Defines a container for message headers
+
+
+
+
Copy
+ constructor
+
+
+
+
Assignment operator
+
+
+
+
Swap function
+
+
+
+
Accesses the message headers
+
+
+
+
+
Accesses the message body
+
+
+
+
Accesses the source of the message
+
+
+
+
Accesses the
+ destination of the message
+
+
+
+
Defines a message with default parameters.
+
+
+
+
+
+
+
+ basic_message is the bare minimum for a class to model
+ the Message concept. It is intended to be extended and customized according
+ to the requirements of different protocols.
+
+ The rendering layer defines the algorithms used to render a message into
+ different formats or types. Rendering functions should apply to any type
+ that models the Message Concept. Functions in the rendering layer take
+ the form:
+
+ The basic_message template has a single argument (Tag).
+ Tags are useful because:
+
+
+
+ It's possible to specialize the message for different storage requirements;
+
+
+ It's possible to extend the message to support different network protocols.
+
+
+
+ The storage requirements for each of these can differ depending on factors
+ such as the string encoding type or memory usage. For different reasons,
+ its possible to assume a string implementation might be:
+
+ The transformation layer defines the algorithms that can be applied on
+ messages to transform parts or whole messages into different forms or representations.
+ Transformations should apply to any type that models the Message concept.
+ Functions in the transform layer take the form:
+
+ The library includes a URI object and parser implementation that allows users
+ of the library to easily interact with different kinds of valid URI formats.
+
+
+ Currently the library supports a bare URI implementation that only parsers
+ the scheme and leaves the scheme specific part as is, as well as a very liberal
+ HTTP URI parser. The HTTP URI object only supports absolute URIs that start
+ with either 'http' or 'https'.
+
+ This page describes the URI Concepts implemented within cpp-netlib. The
+ following concepts are also implemented as Boost.Concept_check types enforced
+ by the URI library.
+
+
+ URI Concepts are organized into a hierarchy of conepts.
+
+ This page describes the URI Concepts implemented within cpp-netlib. The
+ following concepts are also implemented as Boost.Concept_check types enforced
+ by the URI library.
+
+
+ URI Concepts are organized into a hierarchy of conepts.
+
+ The C++ Network Library was founded by Dean Michael Berris in 2007. Initially
+ it consisted of a message template and an HTTP client. It found a home on
+ [[http://sourceforge.net/projectscpp-netlib][sourceforge]]
+ but was recently migrated to [[http://github.com/mikhailberis/cpp-netlib][github]]
+ where development is actively continued by a committed community.
+
+ Modern applications that communicate over the internet have never been more
+ prevalent, ranging through diverse areas such as high performance servers
+ to embedded systems for smart phones or navigation systems.
+
+
+ Currently, there are no open source network libraries available that use
+ modern object-oriented techniques in C++. With the introduction of Boost.Asio, developing
+ portable network C++ applications has become a very much easier task. What
+ is still lacking is a set of libraries that utilise Boost.Asio
+ in order to provide application level support so that C++ developers are
+ able to develop internet and distributed applications more effectively.
+
+ The objectives of the C++ Network Library are to:
+
+
+
+ develop a high quality, portable, easy to use C++ networking library
+
+
+ enable developers to easily extend the library
+
+
+ lower the barrier to entry for cross-platform network-aware C++ applications
+
+
+
+ The goal of C++ Network Library has never been to build a fully-featured
+ web server - there are plenty of excellent options already available. The
+ niche that this library targets is for light-weight networking functionality
+ for C++ applications that have demanding performance requirements or memory
+ constraints, but that also need to be portable. This type of application
+ is becoming increasingly common as software becomes more distributed, and
+ applications need to communicate with services.
+
+
+ While many languages provide direct library support for high level network
+ programming, this feature is missing in C++. Therefore, this library has
+ been developed with the intention of eventually being submitted to the Boost C++ Libraries, a collection
+ of general, high quality libraries for C++ developers.
+
+
+ Eventually, C++ Network Library will be extended to support many of the application
+ layer protocols such as SMTP, FTP, SOAP, XMPP etc.
+
+ The message and URI alone don't make a useful library. This section describes
+ some of the common network protocols that are implemented in the C++ Network
+ Library.
+
+ The client encapsulates the connection-mapping logic between
+ the domain and the underlying socket. Access to a resource is managed through
+ the client object.
+
+ Then a client object is created that handles all HTTP requests and responses.
+
+
http::responseresponse=client.get(request);
+
+
+ The client simply performs the requests. The interface is trivially easy.
+ All HTTP methods are supported (HEAD, GET, POST, PUT, DELETE).
+
+
+ There are several advantages to this design:
+
+
+
+ A client object manages the connection, unencumbering
+ the developer with this task;
+
+
+ A request can be used with any instance of the client
+ without binding the client to any destination;
+
+
+ By decoupling the method from the request object it
+ allows developers to create requests that may be re-used (e.g. perform
+ a HEAD first; if the the headers don't fulfil a certain criteria, perform
+ a GET using the same resource).
+
+ Once the request has been made, and the client returns
+ a response object, the rest is simple. This example outputs
+ all the response headers and body, in this case just the Boost homepage.
+
+ http::client::follow_redirects / http::client::follow_redirect
+ follow HTTP redirect(s) (300..307) by looking at the "Location"
+ header provided by the response(s); headers present in the original request
+ are preserved in the subsequent request(s).
+
+ Here is an example of C++ Network Library at it's absolute simplest. It downloads
+ a file over HTTP from a URL given as a command line argument and prints the
+ response to the console.
+
+ The C++ Network Library works with Boost 1.35.0 and greater.
+
+
+ Boost is mostly header only but its necessary to build and link to Boost.System
+ in order to use the C++ Network Library.
+
+
+ Running the tests for the library also requires Python
+ to be available in a directory that is present in the system path. The tests
+ work with Python 2.5.
+
+ Distributed under the Boost Software License, Version 1.0. (See accompanying
+ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
+
+
+
diff --git a/libs/network/doc/html/standalone_HTML.manifest b/libs/network/doc/html/standalone_HTML.manifest
new file mode 100644
index 000000000..79474ef74
--- /dev/null
+++ b/libs/network/doc/html/standalone_HTML.manifest
@@ -0,0 +1,22 @@
+index.html
+c___network_library/quick_start.html
+c___network_library/intro.html
+c___network_library/intro/motivation.html
+c___network_library/intro/objectives.html
+c___network_library/intro/history.html
+c___network_library/using.html
+c___network_library/architecture.html
+c___network_library/architecture/message.html
+c___network_library/architecture/message/tag_dispatching.html
+c___network_library/architecture/message/message_concepts.html
+c___network_library/architecture/message/transformation_layer.html
+c___network_library/architecture/message/rendering_layer.html
+c___network_library/architecture/uri.html
+c___network_library/architecture/uri/uri_concepts.html
+c___network_library/protocol.html
+c___network_library/protocol/http.html
+c___network_library/examples.html
+c___network_library/examples/http_client.html
+c___network_library/examples/simple_wget.html
+c___network_library/reference.html
+c___network_library/acknowledgements.html
diff --git a/libs/network/doc/http.qbk b/libs/network/doc/http.qbk
index b4550c276..80018c01e 100644
--- a/libs/network/doc/http.qbk
+++ b/libs/network/doc/http.qbk
@@ -7,7 +7,8 @@
[section:http HTTP]
-The __cnl__ provides direct support for HTTP. As a motivating example, here is the code again from the __quick_start__.
+The __cnl__ provides direct support for HTTP. As a motivating
+example, here is the code again from the __quick_start__.
#include
#include
@@ -33,7 +34,8 @@ The __cnl__ provides direct support for HTTP. As a motivating example, here is
return 0;
}
-Before walking through exactly what is happening in this example, the principle components are described below:
+Before walking through exactly what is happening in this example, the
+principle components are described below:
[heading HTTP Request]
@@ -42,7 +44,8 @@ Before walking through exactly what is happening in this example, the principle
typedef basic_request request;
}}}
-The [^request] encapsulates information about the request and the resource. It models the Message concept.
+The [^request] encapsulates information about the request and the
+resource. It models the Message concept.
[heading HTTP Client]
@@ -51,7 +54,9 @@ The [^request] encapsulates information about the request and the resource. It
typedef basic_client client;
}}}
-The [^client] encapsulates the connection-mapping logic between the domain and the underlying socket. Access to a resource is managed through the [^client] object.
+The [^client] encapsulates the connection-mapping logic between the
+domain and the underlying socket. Access to a resource is managed
+through the [^client] object.
[heading HTTP Response]
@@ -60,7 +65,8 @@ The [^client] encapsulates the connection-mapping logic between the domain and t
typedef basic_response response;
}}}
-The [^response] encapsulates the data received from the server. It also models the Message concept.
+The [^response] encapsulates the data received from the server. It
+also models the Message concept.
[heading Walkthrough]
@@ -70,17 +76,24 @@ This line frames the request for the resource __boost_org__.
http::client client;
-Then a client object is created that handles all HTTP requests and responses.
+Then a client object is created that handles all HTTP requests and
+responses.
http::response response = client.get(request);
-The client simply performs the requests. The interface is trivially easy. All HTTP methods are supported (HEAD, GET, POST, PUT, DELETE).
+The client simply performs the requests. The interface is trivially
+easy. All HTTP methods are supported (HEAD, GET, POST, PUT, DELETE).
There are several advantages to this design:
-# A [^client] object manages the connection, unencumbering the developer with this task;
-# A [^request] can be used with any instance of the [^client] without binding the [^client] to any destination;
-# By decoupling the method from the [^request] object it allows developers to create requests that may be re-used (e.g. perform a HEAD first; if the the headers don't fulfil a certain criteria, perform a GET using the same resource).
+# A [^client] object manages the connection, unencumbering the
+ developer with this task;
+# A [^request] can be used with any instance of the [^client] without
+ binding the [^client] to any destination;
+# By decoupling the method from the [^request] object it allows
+ developers to create requests that may be re-used (e.g. perform a
+ HEAD first; if the the headers don't fulfil a certain criteria,
+ perform a GET using the same resource).
// print response headers
headers_range::type hdrs = headers(response);
@@ -93,8 +106,9 @@ There are several advantages to this design:
// print response body
std::cout << body(response) << std::endl;
-Once the request has been made, and the [^client] returns a [^response] object, the rest is simple. This example outputs all the response headers and body, in this case just the Boost homepage.
-
+Once the request has been made, and the [^client] returns a
+[^response] object, the rest is simple. This example outputs all the
+response headers and body, in this case just the Boost homepage.
[heading Using [^http::client]]
@@ -112,9 +126,14 @@ HTTP features can be enabled by using constructor arguments:
* [^http::client(http::client::follow_redirect)]
[h5 [^http::client::cache_resolved]]
-This argument enables the caching of resolved endpoints and prevents the client from resolving IP addresses of previously resolved hostnames.
+This argument enables the caching of resolved endpoints and prevents
+the client from resolving IP addresses of previously resolved
+hostnames.
[h5 [^http::client::follow_redirect(s)]]
-[^http::client::follow_redirects] / [^http::client::follow_redirect] follow HTTP redirect(s) (300..307) by looking at the "Location" header provided by the response(s); headers present in the original request are preserved in the subsequent request(s).
+[^http::client::follow_redirects] / [^http::client::follow_redirect]
+follow HTTP redirect(s) (300..307) by looking at the "Location" header
+provided by the response(s); headers present in the original request
+are preserved in the subsequent request(s).
[endsect] [/http]
diff --git a/libs/network/doc/intro.qbk b/libs/network/doc/intro.qbk
index f57df452f..11259ee01 100644
--- a/libs/network/doc/intro.qbk
+++ b/libs/network/doc/intro.qbk
@@ -9,9 +9,17 @@
[section:intro Introduction]
[section:motivation Motivation]
-Modern applications that communicate over the internet have never been more prevalent, ranging through diverse areas such as high performance servers to embedded systems for smart phones or navigation systems.
+Modern applications that communicate over the internet have never been
+more prevalent, ranging through diverse areas such as high performance
+servers to embedded systems for smart phones or navigation systems.
-Currently, there are no open source network libraries available that use modern object-oriented techniques in C++. With the introduction of __boost_asio__, developing portable network C++ applications has become a very much easier task. What is still lacking is a set of libraries that utilise __boost_asio__ in order to provide application level support so that C++ developers are able to develop internet and distributed applications more effectively.
+Currently, there are no open source network libraries available that
+use modern object-oriented techniques in C++. With the introduction
+of __boost_asio__, developing portable network C++ applications has
+become a very much easier task. What is still lacking is a set of
+libraries that utilise __boost_asio__ in order to provide application
+level support so that C++ developers are able to develop internet and
+distributed applications more effectively.
[endsect] [/motivation]
@@ -20,18 +28,36 @@ The objectives of the __cnl__ are to:
* develop a high quality, portable, easy to use C++ networking library
* enable developers to easily extend the library
-* lower the barrier to entry for cross-platform network-aware C++ applications
+* lower the barrier to entry for cross-platform network-aware C++
+ applications
-The goal of __cnl__ has never been to build a fully-featured web server - there are plenty of excellent options already available. The niche that this library targets is for light-weight networking functionality for C++ applications that have demanding performance requirements or memory constraints, but that also need to be portable. This type of application is becoming increasingly common as software becomes more distributed, and applications need to communicate with services.
+The goal of __cnl__ has never been to build a fully-featured web
+server - there are plenty of excellent options already available. The
+niche that this library targets is for light-weight networking
+functionality for C++ applications that have demanding performance
+requirements or memory constraints, but that also need to be portable.
+This type of application is becoming increasingly common as software
+becomes more distributed, and applications need to communicate with
+services.
-While many languages provide direct library support for high level network programming, this feature is missing in C++. Therefore, this library has been developed with the intention of eventually being submitted to __boost__, a collection of general, high quality libraries for C++ developers.
+While many languages provide direct library support for high level
+network programming, this feature is missing in C++. Therefore, this
+library has been developed with the intention of eventually being
+submitted to __boost__, a collection of general, high quality
+libraries for C++ developers.
-Eventually, __cnl__ will be extended to support many of the application layer protocols such as SMTP, FTP, SOAP, XMPP etc.
+Eventually, __cnl__ will be extended to support many of the
+application layer protocols such as SMTP, FTP, SOAP, XMPP etc.
[endsect] [/objectives]
[section:history History]
-The __cnl__ was founded by Dean Michael Berris in 2007. Initially it consisted of a message template and an HTTP client. It found a home on [[http://sourceforge.net/projects/cpp-netlib/][sourceforge]] but was recently migrated to [[http://github.com/mikhailberis/cpp-netlib][github]] where development is actively continued by a committed community.
+The __cnl__ was founded by Dean Michael Berris in 2007. Initially it
+consisted of a message template and an HTTP client. It found a home
+on [[http://sourceforge.net/projects/cpp-netlib/][sourceforge]] but
+was recently migrated to
+[[http://github.com/mikhailberis/cpp-netlib][github]] where
+development is actively continued by a committed community.
[endsect] [/history]
diff --git a/libs/network/doc/message.qbk b/libs/network/doc/message.qbk
index 82956fa74..044b32ba9 100644
--- a/libs/network/doc/message.qbk
+++ b/libs/network/doc/message.qbk
@@ -7,21 +7,31 @@
[section:message The Message]
-The initial concept behind the __cnl__ is the __message__ template. The advantage of this is that __message__ can be specialized for different protocol implementations.
+The initial concept behind the __cnl__ is the __message__
+template. The advantage of this is that __message__ can be specialized
+for different protocol implementations.
__message__ is presented below:
[import message.cpp]
[boost_network_message]
-__message__ is the bare minimum for a class to model the Message concept. It is intended to be extended and customized according to the requirements of different protocols.
+__message__ is the bare minimum for a class to model the Message
+concept. It is intended to be extended and customized according to
+the requirements of different protocols.
[section:tag_dispatching Tag Dispatching]
-The __message__ template has a single argument (Tag). Tags are useful because:
+The __message__ template has a single argument (Tag). Tags are useful
+because:
-# It's possible to specialize the message for different storage requirements;
-# It's possible to extend the message to support different network protocols.
+# It's possible to specialize the message for different storage
+ requirements;
+# It's possible to extend the message to support different network
+ protocols.
-The storage requirements for each of these can differ depending on factors such as the string encoding type or memory usage. For different reasons, its possible to assume a string implementation might be:
+The storage requirements for each of these can differ depending on
+factors such as the string encoding type or memory usage. For
+different reasons, its possible to assume a string implementation
+might be:
# [^std::string]
# [^std::wstring]
@@ -29,7 +39,8 @@ The storage requirements for each of these can differ depending on factors such
# [@http://msdn.microsoft.com/en-us/library/ms174288.aspx [^CString]]
# [@http://doc.trolltech.com/qstring.html [^QString]]
-The __cnl__ uses tag dispatching to specialize the message interface at compile time.
+The __cnl__ uses tag dispatching to specialize the message interface
+at compile time.
namespace boost {
namespace network {
@@ -56,7 +67,8 @@ The __cnl__ uses tag dispatching to specialize the message interface at compile
} // namespace network
} // namespace boost
-This technique is extended to two more metafunctions that are used by __message__:
+This technique is extended to two more metafunctions that are used by
+__message__:
namespace boost {
namespace network {
@@ -79,7 +91,12 @@ This technique is extended to two more metafunctions that are used by __message_
[endsect] [/tag_dispatching]
[section:message_concepts Concepts]
-__message__ is [@http://www.boost.org/doc/html/DefaultConstructible.html DefaultConstructible], [@http://www.boost.org/doc/html/CopyConstructible.html CopyConstructible] and [@http://www.boost.org/doc/html/Assignable.html Assignable].
+__message__ is
+[@http://www.boost.org/doc/html/DefaultConstructible.html
+DefaultConstructible],
+[@http://www.boost.org/doc/html/CopyConstructible.html
+CopyConstructible] and [@http://www.boost.org/doc/html/Assignable.html
+Assignable].
[section:message_concept Message]
@@ -116,7 +133,10 @@ usage semantics, and is DefaultConstructible and EqualityComparable.
[endsect] [/message_concepts]
[section:transformation_layer Transformation layer]
-The transformation layer defines the algorithms that can be applied on messages to transform parts or whole messages into different forms or representations. Transformations should apply to any type that models the Message concept. Functions in the transform layer take the form:
+The transformation layer defines the algorithms that can be applied on
+messages to transform parts or whole messages into different forms or
+representations. Transformations should apply to any type that models
+the Message concept. Functions in the transform layer take the form:
template <
class Tag
@@ -126,7 +146,10 @@ The transformation layer defines the algorithms that can be applied on messages
[endsect] [/transformation_layer]
[section:rendering_layer Rendering layer]
-The rendering layer defines the algorithms used to render a message into different formats or types. Rendering functions should apply to any type that models the Message Concept. Functions in the rendering layer take the form:
+The rendering layer defines the algorithms used to render a message
+into different formats or types. Rendering functions should apply to
+any type that models the Message Concept. Functions in the rendering
+layer take the form:
template <
class Tag
diff --git a/libs/network/doc/objectives.qbk b/libs/network/doc/objectives.qbk
index ab6bfcd94..24ed11046 100644
--- a/libs/network/doc/objectives.qbk
+++ b/libs/network/doc/objectives.qbk
@@ -11,12 +11,25 @@ The objectives of the __cnl__ are to:
* develop a high quality, portable, easy to use C++ networking library
* enable developers to easily extend the library
-* lower the barrier to entry for cross-platform network-aware C++ applications
+* lower the barrier to entry for cross-platform network-aware C++
+ applications
-The goal of __cnl__ has never been to build a fully-featured web server - there are plenty of excellent options already available. The niche that this library targets is for light-weight networking functionality for C++ applications that have demanding performance requirements or memory constraints, but that also need to be portable. This type of application is becoming increasingly common as software becomes more distributed, and applications need to communicate with services.
+The goal of __cnl__ has never been to build a fully-featured web
+server - there are plenty of excellent options already available. The
+niche that this library targets is for light-weight networking
+functionality for C++ applications that have demanding performance
+requirements or memory constraints, but that also need to be portable.
+This type of application is becoming increasingly common as software
+becomes more distributed, and applications need to communicate with
+services.
-While many languages provide direct library support for high level network programming, this feature is missing in C++. Therefore, this library has been developed with the intention of eventually being submitted to __boost__, a collection of general, high quality libraries for C++ developers.
+While many languages provide direct library support for high level
+network programming, this feature is missing in C++. Therefore, this
+library has been developed with the intention of eventually being
+submitted to __boost__, a collection of general, high quality
+libraries for C++ developers.
-Eventually, __cnl__ will be extended to support many of the application layer protocols such as SMTP, FTP, SOAP, XMPP etc.
+Eventually, __cnl__ will be extended to support many of the
+application layer protocols such as SMTP, FTP, SOAP, XMPP etc.
[endsect]
diff --git a/libs/network/doc/protocol.qbk b/libs/network/doc/protocol.qbk
index 48bc03a77..8089c6fb9 100644
--- a/libs/network/doc/protocol.qbk
+++ b/libs/network/doc/protocol.qbk
@@ -8,5 +8,7 @@
[section:protocol Application Layer Protocols]
[include http.qbk]
-The message and URI alone don't make a useful library. This section describes some of the common network protocols that are implemented in the __cnl__.
+The message and URI alone don't make a useful library. This section
+describes some of the common network protocols that are implemented in
+the __cnl__.
[endsect]
diff --git a/libs/network/doc/tags_and_directives.qbk b/libs/network/doc/tags_and_directives.qbk
index 73fad4551..e3b9f9507 100644
--- a/libs/network/doc/tags_and_directives.qbk
+++ b/libs/network/doc/tags_and_directives.qbk
@@ -9,7 +9,12 @@
[section:tags_and_directives Tags and Directives]
[heading Directives]
-Attributes can be specialized in this way, but not class member functions. To able to do this, the __cnl__ uses directives. Directives are already familiar in the C++ world as part of the I/O streams in the standard library ([^std::endl], [^std::flush] etc.). For the __cnl__, directives are used to manipulate the message class. A tag aware directive might be implemented as such:
+Attributes can be specialized in this way, but not class member
+functions. To able to do this, the __cnl__ uses directives.
+Directives are already familiar in the C++ world as part of the I/O
+streams in the standard library ([^std::endl], [^std::flush] etc.).
+For the __cnl__, directives are used to manipulate the message class.
+A tag aware directive might be implemented as such:
namespace boost {
namespace network {
@@ -19,7 +24,8 @@ Attributes can be specialized in this way, but not class member functions. To a
>
class basic_source {
// Constructor.
- basic_source(const typename Tag::string_type &source) : source_(source) {
+ basic_source(const typename Tag::string_type &source)
+ : source_(source) {
}
@@ -44,7 +50,8 @@ Attributes can be specialized in this way, but not class member functions. To a
}
}
-To use directives with messages, different overloads of the free [^operator <<] are provided:
+To use directives with messages, different overloads of the free
+[^operator <<] are provided:
template <
class Tag,
@@ -52,7 +59,8 @@ To use directives with messages, different overloads of the free [^operator <<]
>
inline
basic_message &
- operator << (basic_message &message, const Directive &directive) {
+ operator << (basic_message &message,
+ const Directive &directive) {
directive(message);
return message;
}
@@ -65,7 +73,11 @@ Client code looks like this:
<< body("Hello there chaps!")
;
-This approach allows the developers of the __cnl__ to write network code, and the library users to be able to specialize the message to suit their own requirements. Run-time efficiency is good, because compilers will be able to provide optimizations. An extra advantage is the expressiveness of the code.
+This approach allows the developers of the __cnl__ to write network
+code, and the library users to be able to specialize the message to
+suit their own requirements. Run-time efficiency is good, because
+compilers will be able to provide optimizations. An extra advantage
+is the expressiveness of the code.
[heading Customizing __message__]
@@ -75,9 +87,12 @@ __message__ can be specialized based on three traits:
* [^boost::network::ostringstream]
* [^boost::network::headers_container]
-This means that __message__ is not bound to a particular string type. Moreover, this mechanism allows developers to provide custom conversion handlers for data compression or encryption.
+This means that __message__ is not bound to a particular string type.
+Moreover, this mechanism allows developers to provide custom
+conversion handlers for data compression or encryption.
-The fine-grained design of the tags/traits mechanism is strongly influenced by __boost_type_traits__.
+The fine-grained design of the tags/traits mechanism is strongly
+influenced by __boost_type_traits__.
[endsect]
diff --git a/libs/network/doc/using.qbk b/libs/network/doc/using.qbk
index 48566fbcb..5b5dc4132 100644
--- a/libs/network/doc/using.qbk
+++ b/libs/network/doc/using.qbk
@@ -15,10 +15,12 @@ The __cnl__ is tested on GCC 4.3 on Linux; MSVC 9.0 on Windows Vista.
The __cnl__ works with Boost 1.35.0 and greater.
-Boost is mostly header only but its necessary to build and link to __boost_system__ in order to use the __cnl__.
+Boost is mostly header only but its necessary to build and link to
+__boost_system__ in order to use the __cnl__.
-Running the tests for the library also requires __python__ to be available in a directory that is present in the system path.
-The tests work with __python__ 2.5.
+Running the tests for the library also requires __python__ to be
+available in a directory that is present in the system path. The
+tests work with __python__ 2.5.
[endsect]
+
+typedef typename string<Tag>::type string_type; +
typedef typename headers_container<Tag>::type headers_container_type; + +
basic_message(const basic_message &); +
basic_message &operator = (const basic_message &); +
void swap(basic_message &); + +
headers_container_type & headers() const; +
string_type & body() const; +
string_type & source() const; +
string_type & destination() const; +}; + +
typedef basic_message<tags::default_> message; +}} +