OI9.4.x

The types of client connections available include:



mode -1: "JD3" (stateless, block mode communication, responding to the JD3 list of commands);

mode 0: "Block" (stateless, block mode);

mode 1: "Char" (stateful, character interaction);

mode 2: "Web" (stateless, block mode)

If you are only running (calling from) a web app, would it be more efficient to use mode=2 ?

Hi, Barry.

Yes, that's true, and in fact that's what's being used for OECGI (both .exe and .php versions). Those notes document what the different "types" of connection are so that it's possible to develop your own "client" to talk with the engine server, and/or to define defaults for those types of connections in the eserver.cfg. In practice all the clients we provide (oecgi, cto/arev, netOI, etc.) already specify the full set of information needed for a connection (so the defaults in eserver.cfg aren't needed), and use the appropriate connection type (afaik).

Was there somewhere you thought this needed to be specified?

- Bryan Shumsky

Revelation Software, Inc.

Hi, Barry.

Yes, that's true, and in fact that's what's being used for OECGI (both .exe and .php versions). Those notes document what the different "types" of connection are so that it's possible to develop your own "client" to talk with the engine server, and/or to define defaults for those types of connections in the eserver.cfg. In practice all the clients we provide (oecgi, cto/arev, netOI, etc.) already specify the full set of information needed for a connection (so the defaults in eserver.cfg aren't needed), and use the appropriate connection type (afaik).

Was there somewhere you thought this needed to be specified?

- Bryan Shumsky

Revelation Software, Inc.

Was there somewhere you thought this needed to be specified?

in eserver.cfg - mode=

Now I am confused!!

Hi, Barry.

Yes, that's true, and in fact that's what's being used for OECGI (both .exe and .php versions). Those notes document what the different "types" of connection are so that it's possible to develop your own "client" to talk with the engine server, and/or to define defaults for those types of connections in the eserver.cfg. In practice all the clients we provide (oecgi, cto/arev, netOI, etc.) already specify the full set of information needed for a connection (so the defaults in eserver.cfg aren't needed), and use the appropriate connection type (afaik).

Was there somewhere you thought this needed to be specified?

- Bryan Shumsky

Revelation Software, Inc.

Was there somewhere you thought this needed to be specified?

in eserver.cfg - mode=

Now I am confused!!

Confused = you need eserver.cfg (it seems), but, the settings are ignored when you use oecgi4.exe ?

Hi, Barry. Sorry to have confused you. Let's see if I can make things clearer.

The Engine Server is a "general purpose" service, and it supports a variety of "clients" that need to talk to OpenInsight. It was designed to be an "open" solution, allowing us - or others! - to write software that connects to OI. Over the years, we have created a variety of clients that talk to the engine server (like oecgi, o4w, netOI, CTO, AREV32/AREV64, etc.) which you can use.

Part of the connection process from a client to the engine server is specifying a number of parameters. These include the connection type, the application name, the user name, the password, the startup flags, the shutdown flags, etc. Now, a client can provide (and, in the case of the OI supported clients, DO provide) all the necessary details for a connection. But it's possible to create a client that doesn't, and so the eserver.cfg (which defines the properties of the engine server) allows you to specify what should be the default values if a client tries to connect but DOESN'T specify those details.

As I mentioned before, in practice, we DO provide all the details, and so these default values in the eserver.cfg aren't needed by any of the clients that we give you. If you wanted to come up with your OWN client to the engine server, you might not code it to pass in the application information (for example), and so the eserver.cfg would rely on the default values for that information.

And just to clarify this one extra bit that you highlight:

In practice all the clients we provide (oecgi, cto/arev, netOI, etc.) already specify the full set of information needed for a connection (so the defaults in eserver.cfg aren't needed), and use the appropriate connection type (afaik)

To restate this, with emphasis as appropriate - the _DEFAULTS_ in eserver.cfg aren't needed, so you don't have to specify anything for mode= (for example); eserver.cfg, overall, is still used for a variety of other settings, and so I'm not suggesting that eserver.cfg ITSELF is unneeded.

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

Hi, Barry. Sorry to have confused you. Let's see if I can make things clearer.

The Engine Server is a "general purpose" service, and it supports a variety of "clients" that need to talk to OpenInsight. It was designed to be an "open" solution, allowing us - or others! - to write software that connects to OI. Over the years, we have created a variety of clients that talk to the engine server (like oecgi, o4w, netOI, CTO, AREV32/AREV64, etc.) which you can use.

Part of the connection process from a client to the engine server is specifying a number of parameters. These include the connection type, the application name, the user name, the password, the startup flags, the shutdown flags, etc. Now, a client can provide (and, in the case of the OI supported clients, DO provide) all the necessary details for a connection. But it's possible to create a client that doesn't, and so the eserver.cfg (which defines the properties of the engine server) allows you to specify what should be the default values if a client tries to connect but DOESN'T specify those details.

As I mentioned before, in practice, we DO provide all the details, and so these default values in the eserver.cfg aren't needed by any of the clients that we give you. If you wanted to come up with your OWN client to the engine server, you might not code it to pass in the application information (for example), and so the eserver.cfg would rely on the default values for that information.

And just to clarify this one extra bit that you highlight:

In practice all the clients we provide (oecgi, cto/arev, netOI, etc.) already specify the full set of information needed for a connection (so the defaults in eserver.cfg aren't needed), and use the appropriate connection type (afaik)

To restate this, with emphasis as appropriate - the _DEFAULTS_ in eserver.cfg aren't needed, so you don't have to specify anything for mode= (for example); eserver.cfg, overall, is still used for a variety of other settings, and so I'm not suggesting that eserver.cfg ITSELF is unneeded.

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

Thank you - great explaination.

So, you are saying that you cant override the OECGI4.exe default for the following.

(say)

IdleCheck=30

MaxConnections=30

MaxEngines=20

Or, is there another setting somewhere else.

Thank you - great explaination.

So, you are saying that you cant override the OECGI4.exe default for the following.

(say)

IdleCheck=30

MaxConnections=30

MaxEngines=20

Or, is there another setting somewhere else.

Hi, Barry. Not EVERY value in the eserver.cfg is passed in by the client - there are a number of settings, like IdleCheck, MaxConnections, and MaxEngines, that are actual configuration settings FOR THE ENGINE SERVER, and not connection details FOR A CONNECTION, and so they are ONLY specified by the eserver.cfg.

You can think of it it this way - if a parameter is used by the engine server to control how the engine server itself works (as another example, what port number it should listen on), then that's controlled exclusively by the eserver.cfg. If a parameter is instead used to start up an OEngine, then the details about how that OEngine should be started may (and usually will) come from the client, or may be specified as defaults in the eserver.cfg for those clients that don't specify them. And in practice, all existing clients (as far as I know) DO specify ALL those details, so the defaults for application name, username, password, startup flags, etc. don't need to be in the eserver.cfg.

Again, to summarize:

- settings for the engine server: must be in eserver.cfg, can't be overridden;

- settings for connecting to an oengine: default values may be specified in the eserver.cfg, but the "client" software normally passes them in

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

Thank you - great explaination.

So, you are saying that you cant override the OECGI4.exe default for the following.

(say)

IdleCheck=30

MaxConnections=30

MaxEngines=20

Or, is there another setting somewhere else.

Hi, Barry. Not EVERY value in the eserver.cfg is passed in by the client - there are a number of settings, like IdleCheck, MaxConnections, and MaxEngines, that are actual configuration settings FOR THE ENGINE SERVER, and not connection details FOR A CONNECTION, and so they are ONLY specified by the eserver.cfg.

You can think of it it this way - if a parameter is used by the engine server to control how the engine server itself works (as another example, what port number it should listen on), then that's controlled exclusively by the eserver.cfg. If a parameter is instead used to start up an OEngine, then the details about how that OEngine should be started may (and usually will) come from the client, or may be specified as defaults in the eserver.cfg for those clients that don't specify them. And in practice, all existing clients (as far as I know) DO specify ALL those details, so the defaults for application name, username, password, startup flags, etc. don't need to be in the eserver.cfg.

Again, to summarize:

- settings for the engine server: must be in eserver.cfg, can't be overridden;

- settings for connecting to an oengine: default values may be specified in the eserver.cfg, but the "client" software normally passes them in

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

if a parameter is used by the engine server to control….

Ah, thats the missing link in my head.

so the defaults for application name, username, password, startup flags, etc. don't need to be in the eserver.cfg.

Of course, the registry settings (In my case for srp's http)

Thanks so much.

Thank you - great explaination.

So, you are saying that you cant override the OECGI4.exe default for the following.

(say)

IdleCheck=30

MaxConnections=30

MaxEngines=20

Or, is there another setting somewhere else.

Hi, Barry. Not EVERY value in the eserver.cfg is passed in by the client - there are a number of settings, like IdleCheck, MaxConnections, and MaxEngines, that are actual configuration settings FOR THE ENGINE SERVER, and not connection details FOR A CONNECTION, and so they are ONLY specified by the eserver.cfg.

You can think of it it this way - if a parameter is used by the engine server to control how the engine server itself works (as another example, what port number it should listen on), then that's controlled exclusively by the eserver.cfg. If a parameter is instead used to start up an OEngine, then the details about how that OEngine should be started may (and usually will) come from the client, or may be specified as defaults in the eserver.cfg for those clients that don't specify them. And in practice, all existing clients (as far as I know) DO specify ALL those details, so the defaults for application name, username, password, startup flags, etc. don't need to be in the eserver.cfg.

Again, to summarize:

- settings for the engine server: must be in eserver.cfg, can't be overridden;

- settings for connecting to an oengine: default values may be specified in the eserver.cfg, but the "client" software normally passes them in

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

if a parameter is used by the engine server to control….

Ah, thats the missing link in my head.

so the defaults for application name, username, password, startup flags, etc. don't need to be in the eserver.cfg.

Of course, the registry settings (In my case for srp's http)

Thanks so much.

View this thread on the Works forum...