summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--cpp/demo/Database/Oracle/occi/README65
-rw-r--r--cpp/demo/Database/Oracle/proc/README32
-rw-r--r--cpp/demo/Freeze/backup/README2
-rw-r--r--cpp/demo/Ice/MFC/client/README4
-rw-r--r--cpp/demo/Ice/MFC/server/README4
-rw-r--r--cpp/demo/Ice/README14
-rw-r--r--cpp/demo/Ice/async/README3
-rw-r--r--cpp/demo/Ice/bidir/README8
-rw-r--r--cpp/demo/Ice/hello/README10
-rw-r--r--cpp/demo/Ice/latency/README4
-rw-r--r--cpp/demo/IceGrid/replication/README13
-rw-r--r--cpp/demo/IceGrid/sessionActivation/README2
-rwxr-xr-xcpp/demo/IcePatch2/MFC/README6
-rw-r--r--cpp/demo/IceStorm/README2
-rw-r--r--cpp/demo/IceStorm/clock/README25
-rw-r--r--cpp/demo/IceStorm/counter/README11
-rw-r--r--cpp/demo/IceStorm/replicated/README8
-rw-r--r--cpp/demo/book/README4
-rw-r--r--cpp/demo/book/evictor/README13
-rw-r--r--cpp/demo/book/printer/README2
-rw-r--r--cpp/demo/book/simple_filesystem/README4
-rw-r--r--cpp/src/ca/README1
-rw-r--r--cs/demo/Ice/README14
-rw-r--r--cs/demo/Ice/async/README2
-rw-r--r--cs/demo/Ice/bidir/README8
-rw-r--r--cs/demo/Ice/hello/README2
-rw-r--r--cs/demo/Ice/latency/README4
-rw-r--r--cs/demo/IceGrid/sessionActivation/README2
-rw-r--r--cs/demo/IceStorm/clock/README25
-rw-r--r--cs/demo/book/README4
-rw-r--r--cs/demo/book/evictor/README13
-rw-r--r--cs/demo/book/simple_filesystem/README4
-rw-r--r--java/demo/Ice/README14
-rw-r--r--java/demo/Ice/async/README2
-rw-r--r--java/demo/Ice/bidir/README8
-rw-r--r--java/demo/Ice/hello/README10
-rw-r--r--java/demo/Ice/latency/README4
-rw-r--r--java/demo/IceGrid/sessionActivation/README2
-rw-r--r--java/demo/IceStorm/clock/README25
-rw-r--r--java/demo/book/README2
-rw-r--r--java/demo/book/evictor/README13
-rw-r--r--java/demo/book/printer/README4
-rw-r--r--php/demo/Ice/README2
-rw-r--r--php/demo/Ice/hello/README33
-rw-r--r--php/demo/Ice/value/README2
-rw-r--r--py/demo/Ice/README14
-rw-r--r--py/demo/Ice/async/README2
-rw-r--r--py/demo/Ice/bidir/README8
-rw-r--r--py/demo/Ice/hello/README10
-rw-r--r--py/demo/Ice/latency/README4
-rw-r--r--py/demo/IceGrid/sessionActivation/README2
-rw-r--r--py/demo/IceStorm/clock/README23
-rw-r--r--rb/demo/Ice/README2
-rw-r--r--rb/demo/Ice/hello/README10
-rw-r--r--rb/demo/book/simple_filesystem/README4
-rw-r--r--vb/demo/Ice/README14
-rw-r--r--vb/demo/Ice/async/README2
-rw-r--r--vb/demo/Ice/bidir/README8
-rw-r--r--vb/demo/Ice/hello/README10
-rw-r--r--vb/demo/Ice/latency/README4
-rw-r--r--vb/demo/IceGrid/sessionActivation/README2
-rw-r--r--vb/demo/IceStorm/clock/README23
-rw-r--r--vb/demo/book/README4
-rw-r--r--vb/demo/book/evictor/README13
-rw-r--r--vb/demo/book/simple_filesystem/README4
65 files changed, 315 insertions, 284 deletions
diff --git a/cpp/demo/Database/Oracle/occi/README b/cpp/demo/Database/Oracle/occi/README
index eaeb0b1dcfb..84afc0a8e7f 100644
--- a/cpp/demo/Database/Oracle/occi/README
+++ b/cpp/demo/Database/Oracle/occi/README
@@ -1,59 +1,73 @@
Oracle OCCI demo
================
-This demo shows how to implement an Ice server that uses Oracle through
-its Oracle C++ Call Interface (OCCI) API.
+This demo shows how to implement an Ice server that uses Oracle
+through its Oracle C++ Call Interface (OCCI) API.
It is a fairly simple demo that illustrates how to:
- - map relational data to Ice objects, in particular convert between
+
+ - Map relational data to Ice objects, in particular convert between
Ice and OCCI types.
- - use an OCCI pool to provide Oracle connections to Ice requests.
- - use an Ice servant locator
+ - Use an OCCI pool to provide Oracle connections to Ice requests.
+ - Use an Ice servant locator.
+
Building the demo
-----------------
+
OCCI is only available for some C++ compilers. Make sure to select a
platform and C++ compiler supported by both Ice and OCCI.
- Setup an Oracle database with the traditional EMP/DEPT schema.
-With Oracle server 10.2, the corresponding SQL script is
-$ORACLE_HOME/rdbms/admin/utilsamp.sql.
+ With Oracle server 10.2, the corresponding SQL script is
+ $ORACLE_HOME/rdbms/admin/utilsamp.sql.
-- Ensure that your user (by default, scott) has the CREATE VIEW
-privilege
+- Ensure that your user (by default, scott) has the CREATE VIEW
+ privilege.
- Create object types and views using the provided createTypes.sql
- script, e.g.
+ script. For example:
+
% sqlplus /nolog
SQL> @createTypes.sql
+
This script assumes that you can connect to your database with
- 'scott/tiger@orcl'. If you need another connect-string, please
- edit createTypes.sql
+ 'scott/tiger@orcl'. If you need another connect-string, edit
+ createTypes.sql.
-- Oracle's ott utility needs to connect to the dabatase in order to
- generate code from file 'DbTypes.typ'. The default connect-
- string is "scott/tiger@orcl". If this is not appropriate, please
- edit the corresponding Makefile target, or Custum build rule for
+- Oracle's ott utility needs to connect to the database in order to
+ generate code from the file 'DbTypes.typ'. The default connect-
+ string is "scott/tiger@orcl". If this is not appropriate, edit the
+ corresponding Makefile target, or the Custom build rule for
Visual Studio projects.
-- Set the environment variable ORACLE_HOME to point to your Oracle
- installation home directory.
+- Set the environment variable ORACLE_HOME to point to your Oracle
+ installation home directory.
- On Windows with Visual Studio 2005 Project Files, add the
following directories to your Visual C++ environment:
+
- Include files: $(ORACLE_HOME)\oci\include
+
- Library files: $(ORACLE_HOME)\oci\lib\msvc\vc8
$(ORACLE_HOME)\oci\lib\msvc
- (make sure to list msvc\vc8 before msvc)
+
+ (make sure to list msvc\vc8 before msvc)
+
- Executable files:
+
$(ORACLE_HOME)\oci\lib\msvc\vc8;$(ORACLE_HOME)\bin
- On Windows with Visual Studio .NET 2003 Project Files, add the
-following directories to your Visual C++ environment:
+ following directories to your Visual C++ environment:
+
- Include files: $(ORACLE_HOME)\oci\include
+
- Library files: $(ORACLE_HOME)\oci\lib\msvc\vc71
$(ORACLE_HOME)\oci\lib\msvc
+
- Executable files:
+
$(ORACLE_HOME)\oci\lib\msvc\vc71;$(ORACLE_HOME)\bin
- On Windows, when using nmake Makefiles, please review
@@ -61,14 +75,17 @@ following directories to your Visual C++ environment:
- Then build as usual.
+
Running the demo
----------------
+
- Review the Oracle properties in the config.server file.
-You may need to change them to connect to your Oracle instance.
+ You may need to change them to connect to your Oracle instance.
- Start the server:
-$ server
-- Start the client in a separate terminal:
-$ client
+ $ server
+
+- Start the client in a separate window:
+ $ client
diff --git a/cpp/demo/Database/Oracle/proc/README b/cpp/demo/Database/Oracle/proc/README
index 05e598556f0..16b6b05ca3c 100644
--- a/cpp/demo/Database/Oracle/proc/README
+++ b/cpp/demo/Database/Oracle/proc/README
@@ -1,23 +1,27 @@
Oracle Pro*C/C++ demo
=====================
-This demo shows how to implement an Ice server that uses Oracle through
-its Embedded SQL (Pro*C/C++) API.
+This demo shows how to implement an Ice server that uses Oracle
+through its Embedded SQL (Pro*C/C++) API.
It is a fairly simple demo that illustrates how to:
- - map relational data to Ice objects, in particular convert
+
+ - Map relational data to Ice objects, in particular convert
between Ice and Oracle Pro*C/C++ types.
- - associate an Oracle Pro*C/C++ context and database connection
+ - Associate an Oracle Pro*C/C++ context and database connection
to each thread in the Ice server thread pool.
- - use Ice default servants
+ - Use Ice default servants.
+
Building the demo
-----------------
-On Linux or Unix, set ORACLE_HOME to point to your Oracle installation
+
+On Linux or Unix, set ORACLE_HOME to point to your Oracle installation
home directory. Then build as usual.
On Windows using Visual Studio Project files, you need to add the
following directories to your Visual C++ environment:
+
- Include files: <oracle-home>\precomp\public
- Library files: <oracle-home>\precomp\lib
- Executable files: <oracle-home>\bin
@@ -26,17 +30,21 @@ On Windows with nmake Makefiles, please review Makefile.mak.
Then build as usual.
+
Running the demo
----------------
+
- Setup an Oracle database with the traditional EMP/DEPT schema.
-With Oracle server 10.2, the corresponding SQL script is
-$ORACLE_HOME/rdbms/admin/utilsamp.sql.
+ With Oracle server 10.2, the corresponding SQL script is
+ $ORACLE_HOME/rdbms/admin/utilsamp.sql.
- Review the Oracle.ConnectInfo property in the config.server file.
-You may need to change it to connect to your Oracle instance.
+ You may need to change it to connect to your Oracle instance.
- Start the server:
-$ server
-- Start the client in a separate terminal:
-$ client
+ $ server
+
+- Start the client in a separate window:
+
+ $ client
diff --git a/cpp/demo/Freeze/backup/README b/cpp/demo/Freeze/backup/README
index e6f77404970..5578c36b222 100644
--- a/cpp/demo/Freeze/backup/README
+++ b/cpp/demo/Freeze/backup/README
@@ -24,7 +24,7 @@ directory.
% ./backup incremental
-Performs an incremental backup (only log files) in the the incremental
+Performs an incremental backup (only log files) in the incremental
directory.
The backup script uses the dd program as well as the Berkeley DB
diff --git a/cpp/demo/Ice/MFC/client/README b/cpp/demo/Ice/MFC/client/README
index 9b3b2300506..1199fe570c4 100644
--- a/cpp/demo/Ice/MFC/client/README
+++ b/cpp/demo/Ice/MFC/client/README
@@ -1,6 +1,6 @@
The client-side portion of the MFC hello demo. Note that this demo
-will work against either the MFC server, or any of the other hello
-servers (for example, the one contained in demo/Ice/hello).
+can be used with the MFC server, or any of the other hello servers
+(for example, the one contained in demo/Ice/hello).
To run the demo, first start the server:
diff --git a/cpp/demo/Ice/MFC/server/README b/cpp/demo/Ice/MFC/server/README
index f0243161b8a..cb961b68fef 100644
--- a/cpp/demo/Ice/MFC/server/README
+++ b/cpp/demo/Ice/MFC/server/README
@@ -1,6 +1,6 @@
The server-side portion of the MFC hello demo. Note that this demo
-will work against either the MFC client, or any of the other hello
-clients (for example, the one in demo/Ice/hello).
+can be used with the MFC client or any of the other hello clients
+(for example, the one in demo/Ice/hello).
To run the demo, first start the server:
diff --git a/cpp/demo/Ice/README b/cpp/demo/Ice/README
index 81e822d868b..8ba5b6fa936 100644
--- a/cpp/demo/Ice/README
+++ b/cpp/demo/Ice/README
@@ -2,15 +2,15 @@ Demos in this directory:
- async
- This demo illustrates the use of Asynchronous Message Invocation (AMI)
- and Asynchronous Message Dispatch (AMD).
+ This demo illustrates the use of Asynchronous Message Invocation
+ (AMI) and Asynchronous Message Dispatch (AMD).
- bidir
- This demo shows how to use bidirectional connections for
- callbacks. This is typically used if the server cannot open a
- connection to the client to send callbacks, for example, because
- firewalls block incoming connections to the client.
+ This demo shows how to use bidirectional connections for callbacks.
+ This is typically used if the server cannot open a connection to the
+ client to send callbacks, for example, because firewalls block
+ incoming connections to the client.
- callback
@@ -27,7 +27,7 @@ Demos in this directory:
This demo illustrates how to invoke ordinary (twoway) operations, as
well as how to invoke oneway operations, use datagrams, secure
- invocations, and how to used batched invocations.
+ invocations, and how to use batched invocations.
- invoke
diff --git a/cpp/demo/Ice/async/README b/cpp/demo/Ice/async/README
index 451c4e5abcd..8227e08baf9 100644
--- a/cpp/demo/Ice/async/README
+++ b/cpp/demo/Ice/async/README
@@ -13,6 +13,5 @@ The demo invocation can either have a short response time or require a
significant amount of time to complete. For the long running request
the client uses AMI and the server uses AMD plus a worker thread to
process the request. While a long request is processing, short
-requests are still able to processed and more long requests can be
+requests are still able to be processed and more long requests can be
queued for processing by the worker thread.
-
diff --git a/cpp/demo/Ice/bidir/README b/cpp/demo/Ice/bidir/README
index 07cb3985956..e37baf56213 100644
--- a/cpp/demo/Ice/bidir/README
+++ b/cpp/demo/Ice/bidir/README
@@ -1,7 +1,7 @@
-This demo shows how to use bidirectional connections for
-callbacks. This is typically used if the server cannot open a
-connection to the client to send callbacks, for example, because
-firewalls block incoming connections to the client.
+This demo shows how to use bidirectional connections for callbacks.
+This is typically used if the server cannot open a connection to the
+client to send callbacks, for example, because firewalls block
+incoming connections to the client.
To run the demo, first start the server:
diff --git a/cpp/demo/Ice/hello/README b/cpp/demo/Ice/hello/README
index 6e8f4ed3476..e6538c4913a 100644
--- a/cpp/demo/Ice/hello/README
+++ b/cpp/demo/Ice/hello/README
@@ -11,8 +11,8 @@ $ client
To test timeouts you can use 'T' to set a timeout on the client proxy
and 'P' to set a delayed response in the server to cause a timeout.
-You will notice that two "Hello World!" messages will be printed by the
-server in this case. This is because the sayHello method is marked as
-idempotent in the slice, meaning that Ice does not need to follow the
-at-most-once retry semantics. See manual for more information about
-retry behavior.
+You will notice that two "Hello World!" messages will be printed by
+the server in this case. This is because the sayHello method is marked
+as idempotent in the slice, meaning that Ice does not need to follow
+the at-most-once retry semantics. See the manual for more information
+about retry behavior.
diff --git a/cpp/demo/Ice/latency/README b/cpp/demo/Ice/latency/README
index 1c18a9e4e49..9d0248f3ebc 100644
--- a/cpp/demo/Ice/latency/README
+++ b/cpp/demo/Ice/latency/README
@@ -1,5 +1,5 @@
-A simple latency test that measures the basic call dispatch
-delay of Ice.
+A simple latency test that measures the basic call dispatch delay of
+Ice.
To run the demo, first start the server:
diff --git a/cpp/demo/IceGrid/replication/README b/cpp/demo/IceGrid/replication/README
index 3ac23f89709..bda227f7a52 100644
--- a/cpp/demo/IceGrid/replication/README
+++ b/cpp/demo/IceGrid/replication/README
@@ -29,11 +29,12 @@ icegridadmin command or from the IceGrid Admin GUI. You can of course
also try to kill them. As long as one IceGrid registry is still
running, the client will continue to work.
-Similarly, you can shutdown or kill one of the the server or IceGrid
-node, the client will continue to work.
+Similarly, you can shutdown or kill one of the servers or nodes, and
+the client will continue to work.
Finally, the registries and nodes are configured to redirect their
-standard error and output to stderr.txt and stdout.txt files in their
-data directory. You can view these files using the icegridadmin
-`registry show' or `node show' commands or with the IceGrid Admin
-GUI. The standard error files contain the registry and node traces.
+standard error and output to files in their data directories named
+stderr.txt and stdout.txt. You can view these files using the
+icegridadmin `registry show' or `node show' commands or with the
+IceGrid Admin GUI. The standard error files contain the registry and
+node traces.
diff --git a/cpp/demo/IceGrid/sessionActivation/README b/cpp/demo/IceGrid/sessionActivation/README
index 0dffa9e30f7..7b29606280b 100644
--- a/cpp/demo/IceGrid/sessionActivation/README
+++ b/cpp/demo/IceGrid/sessionActivation/README
@@ -1,6 +1,6 @@
This demo demonstrates the use of the session activation mode where
the server is activated on demand once it is allocated by the client
-and it is deactivated when the client releases the server.
+and deactivated when the client releases the server.
To run the demo, first start the IceGrid service:
diff --git a/cpp/demo/IcePatch2/MFC/README b/cpp/demo/IcePatch2/MFC/README
index 6f0a3686113..859a9a9ea8d 100755
--- a/cpp/demo/IcePatch2/MFC/README
+++ b/cpp/demo/IcePatch2/MFC/README
@@ -24,9 +24,9 @@ a new command window and execute this command:
> mkdir C:\icepatch_download
-Now you can start the IcePatch2 client (You will also need to pass a
-"IcePatch2.Endpoints" argument if you use a endpoint other than the
-one shown above when you start icepatch2server):
+Now you can start the IcePatch2 client (You will also need to pass an
+argument that defines IcePatch2.Endpoints if you use an endpoint other
+than the one shown above when you start icepatch2server):
> patch
diff --git a/cpp/demo/IceStorm/README b/cpp/demo/IceStorm/README
index f16be7d387e..a0caf8cd50d 100644
--- a/cpp/demo/IceStorm/README
+++ b/cpp/demo/IceStorm/README
@@ -6,7 +6,7 @@ Demos in this directory:
- counter
- A simple couter demo to illistrate implementing the observer
+ A simple counter demo to illustrate implementing the observer
pattern using IceStorm.
- replicated
diff --git a/cpp/demo/IceStorm/clock/README b/cpp/demo/IceStorm/clock/README
index 0d6033a7a8c..1f5b44e76f1 100644
--- a/cpp/demo/IceStorm/clock/README
+++ b/cpp/demo/IceStorm/clock/README
@@ -1,6 +1,4 @@
-To run the demo:
-
-Start the IceStorm service:
+To run the demo, start the IceStorm service:
$ icebox --Ice.Config=config.icebox
@@ -28,36 +26,37 @@ For the subscriber:
subscriber --oneway
- The subscriber receives events as oneway messages. This is the default.
+ The subscriber receives events as oneway messages. This is the
+ default.
subscriber --datagram
- The subscriber receives events as datagrams.
+ The subscriber receives events as datagrams.
subscriber --twoway
- The subscriber receives events as twoway messages.
+ The subscriber receives events as twoway messages.
subscriber --ordered
- The subscriber receives events as twoway messages with guaranteed
- ordering.
+ The subscriber receives events as twoway messages with guaranteed
+ ordering.
subscriber --batch
- This is an additional flag that forwards datagram and oneway events
- to the subscriber in batches.
+ This is an additional flag that forwards datagram and oneway events
+ to the subscriber in batches.
For the publisher:
publisher --oneway
- The publisher sends events as oneway messages. This is the default.
+ The publisher sends events as oneway messages. This is the default.
publisher --datagram
- The publisher sends events as datagrams.
+ The publisher sends events as datagrams.
publisher --twoway
- The publisher sends events as twoway messages.
+ The publisher sends events as twoway messages.
diff --git a/cpp/demo/IceStorm/counter/README b/cpp/demo/IceStorm/counter/README
index b8207de7cc9..5421a7e3342 100644
--- a/cpp/demo/IceStorm/counter/README
+++ b/cpp/demo/IceStorm/counter/README
@@ -1,6 +1,4 @@
-To run the demo:
-
-Start the IceStorm service:
+To run the demo, start the IceStorm service:
$ icebox --Ice.Config=config.icebox
@@ -15,7 +13,6 @@ In another window:
$ client
-You can then press 'i', 'd' to increment a decrement the counter. If
-you want you can create more clients in other windows and observe that
-each is initialized and subsequently updated with the current counter
-value.
+Press 'i' and 'd' to increment and decrement the counter. You can also
+start more clients in other windows and observe that each is
+initialized and subsequently updated with the current counter value.
diff --git a/cpp/demo/IceStorm/replicated/README b/cpp/demo/IceStorm/replicated/README
index 8c3a6d1571d..486a65b712c 100644
--- a/cpp/demo/IceStorm/replicated/README
+++ b/cpp/demo/IceStorm/replicated/README
@@ -1,9 +1,7 @@
-This demo demonstrates how to deploy and setup IceStorm in a
+This demo demonstrates how to configure and deploy IceStorm in a
replicated fashion using IceGrid replica groups.
-To run the demo:
-
-Start the IceGrid service:
+To run the demo, start the IceGrid service:
$ icegridnode --Ice.Config=config.grid
@@ -22,7 +20,7 @@ displayed in the subscriber window.
The IceGrid application described in `application.xml' deploys three
IceStorm service instances. The three IceStorm service instances share
-the same instance name and their objet adapters are configured to be
+the same instance name and their object adapters are configured to be
members of IceGrid replica groups.
When the subscriber starts, it retrieves all the topic manager object
diff --git a/cpp/demo/book/README b/cpp/demo/book/README
index d82b7a4e8ae..07162207955 100644
--- a/cpp/demo/book/README
+++ b/cpp/demo/book/README
@@ -3,8 +3,8 @@ Demos in this directory:
- evictor
This is the source code for the evictor implementation described in
- the advanced server chapter. You can copy and modify this code to
- suit your needs.
+ the Ice Run Time chapter. You can copy and modify this code to suit
+ your needs.
- printer
diff --git a/cpp/demo/book/evictor/README b/cpp/demo/book/evictor/README
index aab1dfc4eb8..ef2b2857616 100644
--- a/cpp/demo/book/evictor/README
+++ b/cpp/demo/book/evictor/README
@@ -1,10 +1,11 @@
-The source code provided here implements a C++ evictor base class.
-To use it, you must derive a class from EvictorBase and
-implement the pure virtual add() and evict() methods.
+The source code provided here implements a C++ evictor base class. To
+use it, you must derive a class from EvictorBase and implement the
+pure virtual add() and evict() methods.
+
add() is called when the evictor needs to instantiate a servant, and
evict() is called when the evictor has decided to evict a servant.
Note that you can pass information from add() to the corresponding
-call to evict via the cookie argument.
+call to evict() via the cookie argument.
-For more details on this evictor, see the section Server Implementation
-Techniques in the Ice documentation.
+For more details on this evictor, see the section "Server
+Implementation Techniques" in the Ice documentation.
diff --git a/cpp/demo/book/printer/README b/cpp/demo/book/printer/README
index b63688254f4..bf45df75b3b 100644
--- a/cpp/demo/book/printer/README
+++ b/cpp/demo/book/printer/README
@@ -1,5 +1,5 @@
This demo implements the printer example in chapter 3 of the documentation.
-To run it, start the server in a windows:
+To run it, start the server in a window:
$ server
diff --git a/cpp/demo/book/simple_filesystem/README b/cpp/demo/book/simple_filesystem/README
index 2f0115920fc..936da730c14 100644
--- a/cpp/demo/book/simple_filesystem/README
+++ b/cpp/demo/book/simple_filesystem/README
@@ -1,5 +1,5 @@
-This demo implements the simple filesystem application shown at
-the end of the client and server C++ mapping chapters.
+This demo implements the simple filesystem application shown at the
+end of the client and server C++ mapping chapters.
To run it, start the server in a window:
diff --git a/cpp/src/ca/README b/cpp/src/ca/README
index 21d80094033..ea6bda19c36 100644
--- a/cpp/src/ca/README
+++ b/cpp/src/ca/README
@@ -2,5 +2,4 @@ The Python script in this directory is a wrapper around OpenSSL's
tools to simplify the process of setting up a private certificate
authority and generating certificates.
-
See the IceSSL chapter of the Ice manual for usage instructions.
diff --git a/cs/demo/Ice/README b/cs/demo/Ice/README
index 4cf012b1ebf..6dbee2c5a4c 100644
--- a/cs/demo/Ice/README
+++ b/cs/demo/Ice/README
@@ -2,15 +2,15 @@ Demos in this directory:
- async
- This demo illustrates the use of Asynchronous Message Invocation (AMI)
- and Asynchronous Message Dispatch (AMD).
+ This demo illustrates the use of Asynchronous Message Invocation
+ (AMI) and Asynchronous Message Dispatch (AMD).
- bidir
- This demo shows how to use bi-directional connections for
- callbacks. This is typically used if the server cannot open a
- connection to the client to send callbacks, for example, because
- firewalls block incoming connections to the client.
+ This demo shows how to use bidirectional connections for callbacks.
+ This is typically used if the server cannot open a connection to the
+ client to send callbacks, for example, because firewalls block
+ incoming connections to the client.
- callback
@@ -23,7 +23,7 @@ Demos in this directory:
This demo illustrates how to invoke ordinary (twoway) operations, as
well as how to invoke oneway operations, use datagrams, secure
- invocations, and how to used batched invocations.
+ invocations, and how to use batched invocations.
- invoke
diff --git a/cs/demo/Ice/async/README b/cs/demo/Ice/async/README
index ebe8032b821..95cf766462a 100644
--- a/cs/demo/Ice/async/README
+++ b/cs/demo/Ice/async/README
@@ -13,5 +13,5 @@ The demo invocation can either have a short response time or require a
significant amount of time to complete. For the long running request
the client uses AMI and the server uses AMD plus a worker thread to
process the request. While a long request is processing, short
-requests are still able to processed and more long requests can be
+requests are still able to be processed and more long requests can be
queued for processing by the worker thread.
diff --git a/cs/demo/Ice/bidir/README b/cs/demo/Ice/bidir/README
index 0fb47657db8..201ed936bed 100644
--- a/cs/demo/Ice/bidir/README
+++ b/cs/demo/Ice/bidir/README
@@ -1,7 +1,7 @@
-This demo shows how to use bi-directional connections for
-callbacks. This is typically used if the server cannot open a
-connection to the client to send callbacks, for example, because
-firewalls block incoming connections to the client.
+This demo shows how to use bidirectional connections for callbacks.
+This is typically used if the server cannot open a connection to the
+client to send callbacks, for example, because firewalls block
+incoming connections to the client.
To run the demo, first start the server:
diff --git a/cs/demo/Ice/hello/README b/cs/demo/Ice/hello/README
index 393bcd7dfc9..5448473833c 100644
--- a/cs/demo/Ice/hello/README
+++ b/cs/demo/Ice/hello/README
@@ -14,5 +14,5 @@ and 'P' to set a delayed response in the server to cause a timeout.
You will notice that two "Hello World!" messages will be printed by the
server in this case. This is because the sayHello method is marked as
idempotent in the slice, meaning that Ice does not need to follow the
-at-most-once retry semantics. See manual for more information about
+at-most-once retry semantics. See the manual for more information about
retry behavior.
diff --git a/cs/demo/Ice/latency/README b/cs/demo/Ice/latency/README
index d501d4faf2a..46ee496d461 100644
--- a/cs/demo/Ice/latency/README
+++ b/cs/demo/Ice/latency/README
@@ -1,5 +1,5 @@
-A simple latency test that measures the basic call dispatch
-delay of Ice.
+A simple latency test that measures the basic call dispatch delay of
+Ice.
To run the demo, first start the server:
diff --git a/cs/demo/IceGrid/sessionActivation/README b/cs/demo/IceGrid/sessionActivation/README
index 7a22870d5d3..bf7c3af0ca9 100644
--- a/cs/demo/IceGrid/sessionActivation/README
+++ b/cs/demo/IceGrid/sessionActivation/README
@@ -20,7 +20,7 @@ Note for Mono:
This demo demonstrates the use of the session activation mode where
the server is activated on demand once it is allocated by the client
-and it is deactivated when the client releases the server.
+and deactivated when the client releases the server.
To run the demo, first start the IceGrid service:
diff --git a/cs/demo/IceStorm/clock/README b/cs/demo/IceStorm/clock/README
index 9f15e43a489..ce09191df5b 100644
--- a/cs/demo/IceStorm/clock/README
+++ b/cs/demo/IceStorm/clock/README
@@ -1,6 +1,4 @@
-To run the demo:
-
-Start the IceStorm service:
+To run the demo, start the IceStorm service:
$ icebox --Ice.Config=config.icebox
@@ -28,36 +26,37 @@ For the subscriber:
subscriber.exe --oneway
- The subscriber receives events as oneway messages. This is the default.
+ The subscriber receives events as oneway messages. This is the
+ default.
subscriber.exe --datagram
- The subscriber receives events as datagrams.
+ The subscriber receives events as datagrams.
subscriber.exe --twoway
- The subscriber receives events as twoway messages.
+ The subscriber receives events as twoway messages.
subscriber.exe --ordered
- The subscriber receives events as twoway messages with guaranteed
- ordering.
+ The subscriber receives events as twoway messages with guaranteed
+ ordering.
subscriber.exe --batch
- This is an additional flag that forwards datagram and oneway events
- to the subscriber in batches.
+ This is an additional flag that forwards datagram and oneway events
+ to the subscriber in batches.
For the publisher:
publisher.exe --oneway
- The publisher sends events as oneway messages. This is the default.
+ The publisher sends events as oneway messages. This is the default.
publisher.exe --datagram
- The publisher sends events as datagrams.
+ The publisher sends events as datagrams.
publisher.exe --twoway
- The publisher sends events as twoway messages.
+ The publisher sends events as twoway messages.
diff --git a/cs/demo/book/README b/cs/demo/book/README
index d82b7a4e8ae..07162207955 100644
--- a/cs/demo/book/README
+++ b/cs/demo/book/README
@@ -3,8 +3,8 @@ Demos in this directory:
- evictor
This is the source code for the evictor implementation described in
- the advanced server chapter. You can copy and modify this code to
- suit your needs.
+ the Ice Run Time chapter. You can copy and modify this code to suit
+ your needs.
- printer
diff --git a/cs/demo/book/evictor/README b/cs/demo/book/evictor/README
index 0710d78a283..7fefaf297eb 100644
--- a/cs/demo/book/evictor/README
+++ b/cs/demo/book/evictor/README
@@ -1,14 +1,15 @@
-The source code provided here implements a C# evictor base class.
-To use it, you must derive a class from EvictorBase and
-implement the abstract add() and evict() methods.
+The source code provided here implements a C# evictor base class. To
+use it, you must derive a class from EvictorBase and implement the
+abstract add() and evict() methods.
+
add() is called when the evictor needs to instantiate a servant, and
evict() is called when the evictor has decided to evict a servant.
Note that you can pass information from add() to the corresponding
-call to evict via the cookie argument.
+call to evict() via the cookie argument.
The evictor implementation relies on a linked list that allows items
to be added and removed without invalidating iterators. Such an
implementation is provided in LinkedList.cs.
-For more details on this evictor, see the section Server Implementation
-Techniques in the Ice documentation.
+For more details on this evictor, see the section "Server
+Implementation Techniques" in the Ice documentation.
diff --git a/cs/demo/book/simple_filesystem/README b/cs/demo/book/simple_filesystem/README
index fcd626aa4ce..8cb787f1674 100644
--- a/cs/demo/book/simple_filesystem/README
+++ b/cs/demo/book/simple_filesystem/README
@@ -1,5 +1,5 @@
-This demo implements the simple filesystem application shown at
-the end of the client and server C# mapping chapters.
+This demo implements the simple filesystem application shown at the
+end of the client and server C# mapping chapters.
To run it, start the server in a window:
diff --git a/java/demo/Ice/README b/java/demo/Ice/README
index 4cf012b1ebf..6dbee2c5a4c 100644
--- a/java/demo/Ice/README
+++ b/java/demo/Ice/README
@@ -2,15 +2,15 @@ Demos in this directory:
- async
- This demo illustrates the use of Asynchronous Message Invocation (AMI)
- and Asynchronous Message Dispatch (AMD).
+ This demo illustrates the use of Asynchronous Message Invocation
+ (AMI) and Asynchronous Message Dispatch (AMD).
- bidir
- This demo shows how to use bi-directional connections for
- callbacks. This is typically used if the server cannot open a
- connection to the client to send callbacks, for example, because
- firewalls block incoming connections to the client.
+ This demo shows how to use bidirectional connections for callbacks.
+ This is typically used if the server cannot open a connection to the
+ client to send callbacks, for example, because firewalls block
+ incoming connections to the client.
- callback
@@ -23,7 +23,7 @@ Demos in this directory:
This demo illustrates how to invoke ordinary (twoway) operations, as
well as how to invoke oneway operations, use datagrams, secure
- invocations, and how to used batched invocations.
+ invocations, and how to use batched invocations.
- invoke
diff --git a/java/demo/Ice/async/README b/java/demo/Ice/async/README
index bef4df5d1fd..875f851a8d6 100644
--- a/java/demo/Ice/async/README
+++ b/java/demo/Ice/async/README
@@ -13,5 +13,5 @@ The demo invocation can either have a short response time or require a
significant amount of time to complete. For the long running request
the client uses AMI and the server uses AMD plus a worker thread to
process the request. While a long request is processing, short
-requests are still able to processed and more long requests can be
+requests are still able to be processed and more long requests can be
queued for processing by the worker thread.
diff --git a/java/demo/Ice/bidir/README b/java/demo/Ice/bidir/README
index def66e6f7c0..d2fc8d76798 100644
--- a/java/demo/Ice/bidir/README
+++ b/java/demo/Ice/bidir/README
@@ -1,7 +1,7 @@
-This demo shows how to use bi-directional connections for
-callbacks. This is typically used if the server cannot open a
-connection to the client to send callbacks, for example, because
-firewalls block incoming connections to the client.
+This demo shows how to use bidirectional connections for callbacks.
+This is typically used if the server cannot open a connection to the
+client to send callbacks, for example, because firewalls block
+incoming connections to the client.
To run the demo, first start the server:
diff --git a/java/demo/Ice/hello/README b/java/demo/Ice/hello/README
index 87a281d58a6..0cc7c5b7cc9 100644
--- a/java/demo/Ice/hello/README
+++ b/java/demo/Ice/hello/README
@@ -11,8 +11,8 @@ $ java Client
To test timeouts you can use 'T' to set a timeout on the client proxy
and 'P' to set a delayed response in the server to cause a timeout.
-You will notice that two "Hello World!" messages will be printed by the
-server in this case. This is because the sayHello method is marked as
-idempotent in the slice, meaning that Ice does not need to follow the
-at-most-once retry semantics. See manual for more information about
-retry behavior.
+You will notice that two "Hello World!" messages will be printed by
+the server in this case. This is because the sayHello method is marked
+as idempotent in the slice, meaning that Ice does not need to follow
+the at-most-once retry semantics. See the manual for more information
+about retry behavior.
diff --git a/java/demo/Ice/latency/README b/java/demo/Ice/latency/README
index 887b526f6f9..f773d5c8b55 100644
--- a/java/demo/Ice/latency/README
+++ b/java/demo/Ice/latency/README
@@ -1,5 +1,5 @@
-A simple latency test that measures the basic call dispatch
-delay of Ice.
+A simple latency test that measures the basic call dispatch delay of
+Ice.
To run the demo, first start the server:
diff --git a/java/demo/IceGrid/sessionActivation/README b/java/demo/IceGrid/sessionActivation/README
index 49148e781bc..b66bd5e8f08 100644
--- a/java/demo/IceGrid/sessionActivation/README
+++ b/java/demo/IceGrid/sessionActivation/README
@@ -1,6 +1,6 @@
This demo demonstrates the use of the session activation mode where
the server is activated on demand once it is allocated by the client
-and it is deactivated when the client releases the server.
+and deactivated when the client releases the server.
To run the demo, first start the IceGrid service:
diff --git a/java/demo/IceStorm/clock/README b/java/demo/IceStorm/clock/README
index acc1506736d..9339189ee30 100644
--- a/java/demo/IceStorm/clock/README
+++ b/java/demo/IceStorm/clock/README
@@ -15,49 +15,50 @@ In another window:
$ java Publisher
-While the publisher continues to run "tick" messages should be
+While the publisher continues to run, "tick" messages should be
displayed in the subscriber window.
Both the subscriber and publisher take an optional topic name as a
final argument. The default value for this topic is "time".
-Through the use of command-line options both the subscriber and
+Through the use of command-line options, both the subscriber and
publisher can use different QoS for sending and receiving messages.
For the subscriber:
java Subscriber --oneway
- The subscriber receives events as oneway messages. This is the default.
+ The subscriber receives events as oneway messages. This is the
+ default.
java Subscriber --datagram
- The subscriber receives events as datagrams.
+ The subscriber receives events as datagrams.
java Subscriber --twoway
- The subscriber receives events as twoway messages.
+ The subscriber receives events as twoway messages.
java Subscriber --ordered
- The subscriber receives events as twoway messages with guaranteed
- ordering.
+ The subscriber receives events as twoway messages with guaranteed
+ ordering.
java Subscriber --batch
- This is an additional flag that forwards datagram and oneway events
- to the subscriber in batches.
+ This is an additional flag that forwards datagram and oneway events
+ to the subscriber in batches.
For the publisher:
java Publisher --oneway
- The publisher sends events as oneway messages. This is the default.
+ The publisher sends events as oneway messages. This is the default.
java Publisher --datagram
- The publisher sends events as datagrams.
+ The publisher sends events as datagrams.
java Publisher --twoway
- The publisher sends events as twoway messages.
+ The publisher sends events as twoway messages.
diff --git a/java/demo/book/README b/java/demo/book/README
index d82b7a4e8ae..c269a7ead90 100644
--- a/java/demo/book/README
+++ b/java/demo/book/README
@@ -3,7 +3,7 @@ Demos in this directory:
- evictor
This is the source code for the evictor implementation described in
- the advanced server chapter. You can copy and modify this code to
+ the Ice Run Time chapter. You can copy and modify this code to
suit your needs.
- printer
diff --git a/java/demo/book/evictor/README b/java/demo/book/evictor/README
index 01b304481ea..cc6b56f5d65 100644
--- a/java/demo/book/evictor/README
+++ b/java/demo/book/evictor/README
@@ -1,14 +1,15 @@
-The source code provided here implements a Java evictor base class.
-To use it, you must derive a class from EvictorBase and
-implement the abstract add() and evict() methods.
+The source code provided here implements a Java evictor base class. To
+use it, you must derive a class from EvictorBase and implement the
+abstract add() and evict() methods.
+
add() is called when the evictor needs to instantiate a servant, and
evict() is called when the evictor has decided to evict a servant.
Note that you can pass information from add() to the corresponding
-call to evict via the cookie argument.
+call to evict() via the cookie argument.
The evictor implementation relies on a linked list that allows items
to be added and removed without invalidating iterators. Such an
implementation is provided in LinkedList.java.
-For more details on this evictor, see the section Server Implementation
-Techniques in the Ice documentation.
+For more details on this evictor, see the section "Server
+Implementation Techniques" in the Ice documentation.
diff --git a/java/demo/book/printer/README b/java/demo/book/printer/README
index b874377e89c..38d5c0f402d 100644
--- a/java/demo/book/printer/README
+++ b/java/demo/book/printer/README
@@ -1,5 +1,5 @@
-This demo implements the printer example in chapter 3 of the documentation.
-To run it, start the server in a windows:
+This demo implements the printer example in chapter 3 of the
+documentation. To run it, start the server in a window:
$ java Server
diff --git a/php/demo/Ice/README b/php/demo/Ice/README
index 48bf829bf79..eed54117d0e 100644
--- a/php/demo/Ice/README
+++ b/php/demo/Ice/README
@@ -4,7 +4,7 @@ Demos in this directory:
This demo illustrates how to invoke ordinary (twoway) operations, as
well as how to invoke oneway operations, use datagrams, secure
- invocations, and how to used batched invocations.
+ invocations, and how to use batched invocations.
- value
diff --git a/php/demo/Ice/hello/README b/php/demo/Ice/hello/README
index e7f28323f85..7c3e5a50d8c 100644
--- a/php/demo/Ice/hello/README
+++ b/php/demo/Ice/hello/README
@@ -28,33 +28,40 @@ Note that support for secure invocations via SSL are disabled by
default. If you have configured SSL for the Ice extension, edit
hello.php and set the have_ssl variable to true.
+
=========================================================================
SELinux Notes
=========================================================================
-On RHEL Linux and a number of other Linux distributions, SELinux
-augments the traditional Unix permissions with a number of new features.
-In particular, SELinux can prevent the httpd daemon from opening
-network connections and reading files without the proper SELinux types.
+SELinux augments the traditional Unix permissions with a number of
+new features. In particular, SELinux can prevent the httpd daemon from
+opening network connections and reading files without the proper
+SELinux types.
If you suspect that your IcePHP application does not work due to
-SELinux restrictions, we recommend to first try with SELinux disabled.
-As root, run:
+SELinux restrictions, we recommend that you first try it with SELinux
+disabled. As root, run:
# setenforce 0
to disable SELinux until the next reboot of your computer.
-If you want to run httpd with IcePHP and SELinux enabled, you need to:
- - allow httpd to open network connections:
+If you want to run httpd with IcePHP and SELinux enabled, you must do
+the following:
+
+- Allow httpd to open network connections:
+
# setsebool httpd_can_network_connect=1
- (use the -P option to make this setting persistent across reboots)
- - make sure any .ice file used by your PHP scripts can be read by
+
+ (add the -P option to make this setting persistent across reboots)
+
+- Make sure any .ice file used by your PHP scripts can be read by
httpd. The enclosing directory also needs to be accessible. For
example:
- # chcon -R -t httpd_sys_content_t /opt/MyApp/slice
-See this FAQ for more information on SELinux:
+ # chcon -R -t httpd_sys_content_t /opt/MyApp/slice
-http://fedora.redhat.com/docs/selinux-faq/
+For more information on SELinux in Red Hat Enterprise Linux 4, refer
+to the link below:
+ http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
diff --git a/php/demo/Ice/value/README b/php/demo/Ice/value/README
index d288af493fc..f9c180a4fbf 100644
--- a/php/demo/Ice/value/README
+++ b/php/demo/Ice/value/README
@@ -3,7 +3,7 @@ This is a PHP version of the Ice "value" demo client.
First, start the value demo server, using any of the supported language
mappings, on this host.
-Then, if you are using a RPM installation of ice-php, run the Ice PHP
+Then, if you are using an RPM installation of IcePHP, run the PHP
client:
$ php -f Client.php
diff --git a/py/demo/Ice/README b/py/demo/Ice/README
index a17047e1f7c..7435eb7c771 100644
--- a/py/demo/Ice/README
+++ b/py/demo/Ice/README
@@ -2,15 +2,15 @@ Demos in this directory:
- async
- This demo illustrates the use of Asynchronous Message Invocation (AMI)
- and Asynchronous Message Dispatch (AMD).
+ This demo illustrates the use of Asynchronous Message Invocation
+ (AMI) and Asynchronous Message Dispatch (AMD).
- bidir
- This demo shows how to use bi-directional connections for
- callbacks. This is typically used if the server cannot open a
- connection to the client to send callbacks, for example, because
- firewalls block incoming connections to the client.
+ This demo shows how to use bidirectional connections for callbacks.
+ This is typically used if the server cannot open a connection to the
+ client to send callbacks, for example, because firewalls block
+ incoming connections to the client.
- callback
@@ -23,7 +23,7 @@ Demos in this directory:
This demo illustrates how to invoke ordinary (twoway) operations, as
well as how to invoke oneway operations, use datagrams, secure
- invocations, and how to used batched invocations.
+ invocations, and how to use batched invocations.
- latency
diff --git a/py/demo/Ice/async/README b/py/demo/Ice/async/README
index 874e1656d21..c9491ded9b5 100644
--- a/py/demo/Ice/async/README
+++ b/py/demo/Ice/async/README
@@ -13,5 +13,5 @@ The demo invocation can either have a short response time or require a
significant amount of time to complete. For the long running request
the client uses AMI and the server uses AMD plus a worker thread to
process the request. While a long request is processing, short
-requests are still able to processed and more long requests can be
+requests are still able to be processed and more long requests can be
queued for processing by the worker thread.
diff --git a/py/demo/Ice/bidir/README b/py/demo/Ice/bidir/README
index 4ae0810b75c..e0d0fe84f26 100644
--- a/py/demo/Ice/bidir/README
+++ b/py/demo/Ice/bidir/README
@@ -1,7 +1,7 @@
-This demo shows how to use bi-directional connections for
-callbacks. This is typically used if the server cannot open a
-connection to the client to send callbacks, for example, because
-firewalls block incoming connections to the client.
+This demo shows how to use bidirectional connections for callbacks.
+This is typically used if the server cannot open a connection to the
+client to send callbacks, for example, because firewalls block
+incoming connections to the client.
To run the demo, first start the server:
diff --git a/py/demo/Ice/hello/README b/py/demo/Ice/hello/README
index aebda51f1df..c21bd058a00 100644
--- a/py/demo/Ice/hello/README
+++ b/py/demo/Ice/hello/README
@@ -11,8 +11,8 @@ $ python Client.py
To test timeouts you can use 'T' to set a timeout on the client proxy
and 'P' to set a delayed response in the server to cause a timeout.
-You will notice that two "Hello World!" messages will be printed by the
-server in this case. This is because the sayHello method is marked as
-idempotent in the slice, meaning that Ice does not need to follow the
-at-most-once retry semantics. See manual for more information about
-retry behavior.
+You will notice that two "Hello World!" messages will be printed by
+the server in this case. This is because the sayHello method is marked
+as idempotent in the slice, meaning that Ice does not need to follow
+the at-most-once retry semantics. See the manual for more information
+about retry behavior.
diff --git a/py/demo/Ice/latency/README b/py/demo/Ice/latency/README
index fb73f949344..5f8434068d4 100644
--- a/py/demo/Ice/latency/README
+++ b/py/demo/Ice/latency/README
@@ -1,5 +1,5 @@
-A simple latency test that measures the basic call dispatch
-delay of Ice.
+A simple latency test that measures the basic call dispatch delay of
+Ice.
To run the demo, first start the server:
diff --git a/py/demo/IceGrid/sessionActivation/README b/py/demo/IceGrid/sessionActivation/README
index 4e8902d4fd8..0a665744a28 100644
--- a/py/demo/IceGrid/sessionActivation/README
+++ b/py/demo/IceGrid/sessionActivation/README
@@ -1,6 +1,6 @@
This demo demonstrates the use of the session activation mode where
the server is activated on demand once it is allocated by the client
-and it is deactivated when the client releases the server.
+and deactivated when the client releases the server.
To run the demo, first start the IceGrid service:
diff --git a/py/demo/IceStorm/clock/README b/py/demo/IceStorm/clock/README
index 53467bb46c3..cc5d2375ca5 100644
--- a/py/demo/IceStorm/clock/README
+++ b/py/demo/IceStorm/clock/README
@@ -15,7 +15,7 @@ In another window:
$ python Publisher.py
-While the publisher continues to run "tick" messages should be
+While the publisher continues to run, "tick" messages should be
displayed in the subscriber window.
Both the subscriber and publisher take an optional topic name as a
@@ -28,36 +28,37 @@ For the subscriber:
python Subscriber.py --oneway
- The subscriber receives events as oneway messages. This is the default.
+ The subscriber receives events as oneway messages. This is the
+ default.
python Subscriber.py --datagram
- The subscriber receives events as datagrams.
+ The subscriber receives events as datagrams.
python Subscriber.py --twoway
- The subscriber receives events as twoway messages.
+ The subscriber receives events as twoway messages.
python Subscriber.py --ordered
- The subscriber receives events as twoway messages with guaranteed
- ordering.
+ The subscriber receives events as twoway messages with guaranteed
+ ordering.
python Subscriber.py --batch
- This is an additional flag that forwards datagram and oneway events
- to the subscriber in batches.
+ This is an additional flag that forwards datagram and oneway events
+ to the subscriber in batches.
For the publisher:
python Publisher.py --oneway
- The publisher sends events as oneway messages. This is the default.
+ The publisher sends events as oneway messages. This is the default.
python Publisher.py --datagram
- The publisher sends events as datagrams.
+ The publisher sends events as datagrams.
python Publisher.py --twoway
- The publisher sends events as twoway messages.
+ The publisher sends events as twoway messages.
diff --git a/rb/demo/Ice/README b/rb/demo/Ice/README
index 9c1dccbcdcb..ebebba73974 100644
--- a/rb/demo/Ice/README
+++ b/rb/demo/Ice/README
@@ -4,7 +4,7 @@ Demos in this directory:
This demo illustrates how to invoke ordinary (twoway) operations, as
well as how to invoke oneway operations, use datagrams, secure
- invocations, and how to used batched invocations.
+ invocations, and how to use batched invocations.
- latency
diff --git a/rb/demo/Ice/hello/README b/rb/demo/Ice/hello/README
index 0c58f830419..10dad712bcb 100644
--- a/rb/demo/Ice/hello/README
+++ b/rb/demo/Ice/hello/README
@@ -11,8 +11,8 @@ $ ruby Client.rb
To test timeouts you can use 'T' to set a timeout on the client proxy
and 'P' to set a delayed response in the server to cause a timeout.
-You will notice that two "Hello World!" messages will be printed by the
-server in this case. This is because the sayHello method is marked as
-idempotent in the slice, meaning that Ice does not need to follow the
-at-most-once retry semantics. See manual for more information about
-retry behavior.
+You will notice that two "Hello World!" messages will be printed by
+the server in this case. This is because the sayHello method is marked
+as idempotent in the slice, meaning that Ice does not need to follow
+the at-most-once retry semantics. See the manual for more information
+about retry behavior.
diff --git a/rb/demo/book/simple_filesystem/README b/rb/demo/book/simple_filesystem/README
index 35093e936ca..3190a79b40d 100644
--- a/rb/demo/book/simple_filesystem/README
+++ b/rb/demo/book/simple_filesystem/README
@@ -1,5 +1,5 @@
-This demo implements the simple filesystem application shown at
-the end of the Ruby client-side mapping chapter.
+This demo implements the simple filesystem application shown at the
+end of the Ruby client-side mapping chapter.
You will need to start a server from one of the other supported
language mappings.
diff --git a/vb/demo/Ice/README b/vb/demo/Ice/README
index 4cf012b1ebf..6dbee2c5a4c 100644
--- a/vb/demo/Ice/README
+++ b/vb/demo/Ice/README
@@ -2,15 +2,15 @@ Demos in this directory:
- async
- This demo illustrates the use of Asynchronous Message Invocation (AMI)
- and Asynchronous Message Dispatch (AMD).
+ This demo illustrates the use of Asynchronous Message Invocation
+ (AMI) and Asynchronous Message Dispatch (AMD).
- bidir
- This demo shows how to use bi-directional connections for
- callbacks. This is typically used if the server cannot open a
- connection to the client to send callbacks, for example, because
- firewalls block incoming connections to the client.
+ This demo shows how to use bidirectional connections for callbacks.
+ This is typically used if the server cannot open a connection to the
+ client to send callbacks, for example, because firewalls block
+ incoming connections to the client.
- callback
@@ -23,7 +23,7 @@ Demos in this directory:
This demo illustrates how to invoke ordinary (twoway) operations, as
well as how to invoke oneway operations, use datagrams, secure
- invocations, and how to used batched invocations.
+ invocations, and how to use batched invocations.
- invoke
diff --git a/vb/demo/Ice/async/README b/vb/demo/Ice/async/README
index ebe8032b821..95cf766462a 100644
--- a/vb/demo/Ice/async/README
+++ b/vb/demo/Ice/async/README
@@ -13,5 +13,5 @@ The demo invocation can either have a short response time or require a
significant amount of time to complete. For the long running request
the client uses AMI and the server uses AMD plus a worker thread to
process the request. While a long request is processing, short
-requests are still able to processed and more long requests can be
+requests are still able to be processed and more long requests can be
queued for processing by the worker thread.
diff --git a/vb/demo/Ice/bidir/README b/vb/demo/Ice/bidir/README
index abce6080ba5..e37baf56213 100644
--- a/vb/demo/Ice/bidir/README
+++ b/vb/demo/Ice/bidir/README
@@ -1,7 +1,7 @@
-This demo shows how to use bi-directional connections for
-callbacks. This is typically used if the server cannot open a
-connection to the client to send callbacks, for example, because
-firewalls block incoming connections to the client.
+This demo shows how to use bidirectional connections for callbacks.
+This is typically used if the server cannot open a connection to the
+client to send callbacks, for example, because firewalls block
+incoming connections to the client.
To run the demo, first start the server:
diff --git a/vb/demo/Ice/hello/README b/vb/demo/Ice/hello/README
index e7409cebc5c..deb2d6cc84c 100644
--- a/vb/demo/Ice/hello/README
+++ b/vb/demo/Ice/hello/README
@@ -11,8 +11,8 @@ $ client
To test timeouts you can use 'T' to set a timeout on the client proxy
and 'P' to set a delayed response in the server to cause a timeout.
-You will notice that two "Hello World!" messages will be printed by the
-server in this case. This is because the sayHello method is marked as
-idempotent in the slice, meaning that Ice does not need to follow the
-at-most-once retry semantics. See manual for more information about
-retry behavior.
+You will notice that two "Hello World!" messages will be printed by
+the server in this case. This is because the sayHello method is marked
+as idempotent in the slice, meaning that Ice does not need to follow
+the at-most-once retry semantics. See the manual for more information
+about retry behavior.
diff --git a/vb/demo/Ice/latency/README b/vb/demo/Ice/latency/README
index 1c18a9e4e49..9d0248f3ebc 100644
--- a/vb/demo/Ice/latency/README
+++ b/vb/demo/Ice/latency/README
@@ -1,5 +1,5 @@
-A simple latency test that measures the basic call dispatch
-delay of Ice.
+A simple latency test that measures the basic call dispatch delay of
+Ice.
To run the demo, first start the server:
diff --git a/vb/demo/IceGrid/sessionActivation/README b/vb/demo/IceGrid/sessionActivation/README
index 5f0b0b9d6ae..b11fe4d6418 100644
--- a/vb/demo/IceGrid/sessionActivation/README
+++ b/vb/demo/IceGrid/sessionActivation/README
@@ -1,6 +1,6 @@
This demo demonstrates the use of the session activation mode where
the server is activated on demand once it is allocated by the client
-and it is deactivated when the client releases the server.
+and deactivated when the client releases the server.
To run the demo, first start the IceGrid service:
diff --git a/vb/demo/IceStorm/clock/README b/vb/demo/IceStorm/clock/README
index 5006163c0ff..5c222822d7b 100644
--- a/vb/demo/IceStorm/clock/README
+++ b/vb/demo/IceStorm/clock/README
@@ -15,7 +15,7 @@ In another window:
$ publisher
-While the publisher continues to run "tick" messages should be
+While the publisher continues to run, "tick" messages should be
displayed in the subscriber window.
Both the subscriber and publisher take an optional topic name as a
@@ -28,36 +28,37 @@ For the subscriber:
subscriber.exe --oneway
- The subscriber receives events as oneway messages. This is the default.
+ The subscriber receives events as oneway messages. This is the
+ default.
subscriber.exe --datagram
- The subscriber receives events as datagrams.
+ The subscriber receives events as datagrams.
subscriber.exe --twoway
- The subscriber receives events as twoway messages.
+ The subscriber receives events as twoway messages.
subscriber.exe --ordered
- The subscriber receives events as twoway messages with guaranteed
- ordering.
+ The subscriber receives events as twoway messages with guaranteed
+ ordering.
subscriber.exe --batch
- This is an additional flag that forwards datagram and oneway events
- to the subscriber in batches.
+ This is an additional flag that forwards datagram and oneway events
+ to the subscriber in batches.
For the publisher:
publisher.exe --oneway
- The publisher sends events as oneway messages. This is the default.
+ The publisher sends events as oneway messages. This is the default.
publisher.exe --datagram
- The publisher sends events as datagrams.
+ The publisher sends events as datagrams.
publisher.exe --twoway
- The publisher sends events as twoway messages.
+ The publisher sends events as twoway messages.
diff --git a/vb/demo/book/README b/vb/demo/book/README
index d82b7a4e8ae..07162207955 100644
--- a/vb/demo/book/README
+++ b/vb/demo/book/README
@@ -3,8 +3,8 @@ Demos in this directory:
- evictor
This is the source code for the evictor implementation described in
- the advanced server chapter. You can copy and modify this code to
- suit your needs.
+ the Ice Run Time chapter. You can copy and modify this code to suit
+ your needs.
- printer
diff --git a/vb/demo/book/evictor/README b/vb/demo/book/evictor/README
index 349dc474199..43d14243bcc 100644
--- a/vb/demo/book/evictor/README
+++ b/vb/demo/book/evictor/README
@@ -1,14 +1,15 @@
-The source code provided here implements a VB evictor base class.
-To use it, you must derive a class from EvictorBase and
-implement the abstract add() and evict() methods.
+The source code provided here implements a VB evictor base class. To
+use it, you must derive a class from EvictorBase and implement the
+abstract add() and evict() methods.
+
add() is called when the evictor needs to instantiate a servant, and
evict() is called when the evictor has decided to evict a servant.
Note that you can pass information from add() to the corresponding
-call to evict via the cookie argument.
+call to evict() via the cookie argument.
The evictor implementation relies on a linked list that allows items
to be added and removed without invalidating iterators. Such an
implementation is provided in LinkedList.vb.
-For more details on this evictor, see the section Server Implementation
-Techniques in the Ice documentation.
+For more details on this evictor, see the section "Server
+Implementation Techniques" in the Ice documentation.
diff --git a/vb/demo/book/simple_filesystem/README b/vb/demo/book/simple_filesystem/README
index ba4da042a87..395c52e416a 100644
--- a/vb/demo/book/simple_filesystem/README
+++ b/vb/demo/book/simple_filesystem/README
@@ -1,5 +1,5 @@
-This demo implements the simple filesystem application shown at
-the end of the client and server VB mapping chapters.
+This demo implements the simple filesystem application shown at the
+end of the client and server VB mapping chapters.
To run it, start the server in a window: