In
fact, a strict reading of the specification says that it should be
Index: doc/omniORBpy/omniORBpy005.html
===================================================================
RCS file: /cvsroot/omniORBpy/doc/omniORBpy/omniORBpy005.html,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- doc/omniORBpy/omniORBpy005.html 2000/08/18 11:40:57 1.2.2.1
+++ doc/omniORBpy/omniORBpy005.html 2000/09/19 11:28:09 1.2.2.2
@@ -49,6 +49,9 @@
| -N |
Do not run the preprocessor. |
+| -T |
+Use a temporary file, not a pipe, for preprocessor output. |
+
| -Wparg[,arg...] |
Send arguments to the preprocessor. |
@@ -101,6 +104,15 @@
omniidl.
+ Windows 9x
The output from the C preprocessor is normally fed to the omniidl
+parser through a pipe. On some Windows 98 machines (but not all!) the
+pipe does not work, and the preprocessor output is echoed to the
+screen. When this happens, the omniidl parser sees an empty file, and
+produces useless stub files with strange long names. To avoid the
+problem, use the `-T' option to create a temporary file
+between the two stages.
+
+
5.1.2 Forward-declared interfaces
If you have an IDL file like:
@@ -173,7 +185,7 @@
The -Wbstdout option is not really useful if you are
invoking omniidl yourself. It is used by omniORB.importIDL(),
-described in section 6.11.
+described in section 6.12.
When you compile an IDL file which #includes other IDL files, omniidl
normally only generates code for the main file, assuming that code for
Index: doc/omniORBpy/omniORBpy006.html
===================================================================
RCS file: /cvsroot/omniORBpy/doc/omniORBpy/omniORBpy006.html,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- doc/omniORBpy/omniORBpy006.html 2000/08/18 11:40:57 1.2.2.1
+++ doc/omniORBpy/omniORBpy006.html 2000/09/19 11:28:09 1.2.2.2
@@ -331,7 +331,18 @@
interoperability.
-6.9 System Exception Handlers
+6.9 GIOP Requesting Principal field
In versions 1.0 and 1.1 of the GIOP specification, request messages
+contain a `principal' field which was intended to identify the client.
+The meaning of the principal field was never specified, and its use is
+now deprecated. The field is not present in GIOP 1.2. omniORB normally
+uses the string `nobody' in the principal field. However,
+some systems (e.g. the GNOME desktop environment) use the principal
+field as an authentication mechanism, so omniORB allows you to
+configure the principal by setting the OMNIORB_PRINCIPAL
+environment variable.
+
+
+6.10 System Exception Handlers
By default, all system exceptions which are raised during an operation
invocation, with the exception of CORBA.TRANSIENT, are
propagated to the application code. Some applications may prefer to
@@ -353,7 +364,7 @@
in the address space.
-6.9.1 CORBA.TRANSIENT handlers
When a CORBA.TRANSIENT exception is raised by the ORB runtime,
+6.10.1 CORBA.TRANSIENT handlers
When a CORBA.TRANSIENT exception is raised by the ORB runtime,
the default behaviour of the proxy objects is to retry indefinitely
until the operation succeeds, with an exponentially increasing delay
(up to a limit) between retries.
@@ -397,7 +408,7 @@
the TRANSIENT exception is raised in the application.
-6.9.2 CORBA.COMM_FAILURE and CORBA.SystemException
There are two other functions for registering exception handlers: one
+6.10.2 CORBA.COMM_FAILURE and CORBA.SystemException
There are two other functions for registering exception handlers: one
for CORBA.COMM_FAILURE, and one for all other
exceptions. For both these cases, the default is for there to be no
handler, so exceptions are propagated to the application.
@@ -408,8 +419,8 @@
In both cases, the call-back function has the same signature
as for TRANSIENT handlers.
-
-6.10 Location forwarding
+
+6.11 Location forwarding
Any CORBA operation invocation can return a LOCATION_FORWARD
message to the caller, indicating that it should retry the invocation
on a new object reference. The standard allows ServantManagers to
@@ -422,8 +433,8 @@
implementation. omniORB.LOCATION_FORWARD is not supported on
omniORB 2.8.0.
-
-6.11 Dynamic importing of IDL
+
+6.12 Dynamic importing of IDL
omniORBpy is usually used with pre-generated stubs. Since Python is a
dynamic language, however, it is possible to compile and import new
stubs at run-time.
Index: doc/omniORBpy/omniORBpy007.html
===================================================================
RCS file: /cvsroot/omniORBpy/doc/omniORBpy/omniORBpy007.html,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- doc/omniORBpy/omniORBpy007.html 2000/08/18 11:40:57 1.2.2.1
+++ doc/omniORBpy/omniORBpy007.html 2000/09/19 11:28:10 1.2.2.2
@@ -17,7 +17,7 @@
Chapter 7 Connection Management
This chapter describes how omniORB manages network connections.
-
+
7.1 Background
In CORBA, the ORB is the `middleware' that allows a client to invoke
an operation on an object without regard to its implementation or
location. In order to invoke an operation on an object, a client needs
@@ -49,7 +49,7 @@
connections and the programming interface to fine tune the management
policy.
-
+
7.2 The Model
omniORB is designed from the ground up to be fully multi-threaded. The
objective is to maximise the degree of concurrency and at the same
time eliminate any unnecessary thread overhead. Another objective is
@@ -88,7 +88,7 @@
value can be increased to a maximum of a thousand or more by changing
the `ulimit' in the shell.
-
+
7.3 Idle Connection Shutdown and Remote Call Timeout
Inside the ORB, a thread is dedicated to scan for idle connections.
The thread looks after both the outgoing connections and the incoming
@@ -123,7 +123,7 @@
-ORBserverCallTimeOutPeriod options. The scan can be disabled
completely by setting the scan granularity to 0.
-
+
7.4 Interoperability Considerations
The IIOP specification allows both the client and the server to
shutdown a connection unilaterally. When one end is about to shutdown
a connection, it should send a closeConnection message to the other
@@ -147,7 +147,7 @@
in the application code and retry, or to turn off the idle connection
shutdown inside the omniORB server.
-
+
7.5 Connection Acceptance
omniORB provides the hook to implement a connection acceptance policy.
Inside the ORB runtime, a thread is dedicated to receive new
Index: doc/omniORBpy/omniORBpy009.html
===================================================================
RCS file: /cvsroot/omniORBpy/doc/omniORBpy/omniORBpy009.html,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- doc/omniORBpy/omniORBpy009.html 2000/08/18 11:40:57 1.1.2.1
+++ doc/omniORBpy/omniORBpy009.html 2000/09/19 11:28:10 1.1.2.2
@@ -26,20 +26,20 @@
1998.
-