I would love to see comm get some sort of automated or
nearly transparent registration name server, making it
even closer to Tk's send than it currently is.
1. with regards to the 'suppress the auto-dectection to
prevent spawning of infinite number of processes' - isn't
this "just" a simple lock of some sort - perhaps an open
socket - that gets released at the appropriate times?
2. what would be the use of comm send without registry?
3. Re: communicating via an environment variable - how about
through the Tcl option database or something? Environment
variables are nasty as they require user intervention - this
mechanism to be transparent needs some other method.
4. It sure would be useful if the resulting mechanism was be
able to support, when needed, cross-machine comm send - so
that multi-user internet apps could be built on the
structure.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ad 1. The scenario I saw was the startup of the registry
immediately upon loading comm. As the registry needs comm
itself comm starts the registry before the registry opened
its server socket. So comm when loaded by the registry does
not find the registry and thus tries to start it again, ad
infinitum. With the current model of starting the registry
only when it is accessed for the first time this cannot
happen as the registry needs comm, but not the part about
accessing the registry itself. Reinhard Max's scenario of
the first application automatically acting as the registry
itself does not have this problem either.
Ad 2. Applications which are coded to know about each other
by some other means. For example an application launching a
child and explicitly telling it on the command line where
to find the parent.
Ad 3. What we need for the scenario is some means of
automatically sharing this information. I don't believe
that the tcl option database can do this. Or do you mean
about setting and querying the option database on an X
server ? Do we have code to do this ? About the user
intervention bit. As this is about an application and its
child processes the environment is passed automatically
without user intervention. ... Ok, the per-user setup
requires work from the user.
Ad 4. comm itself automatically support cross-machine send,
as the hostname is part of the communication handle, and
not only the port to talk to. So we only need a way for
cross-machine registries. A proxy would be a more safe way
IMHO than directly talking to a remote registry. The proxy
can for example to encryption without burdening the local
applications with this task.
Reinhard Max proposed that the first application able to
open the listening socket should automatically act as the
server. If it goes away for wahtever reason one the other
applications opens the socket and starts to act as
registry, with the other applications reregistering.
Another proposal of his is to include a notification
mechanism so that applications can get events if other
applications (de)register. Using that all applications
could maintain a local copy of the registry.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to modify my proposal (one of the applications
becomes the registry server) a little bit. Instead of acting
itself as registry, an application should start a separate
registry process in the background, if it won the election.
This prevents the registry from being blocked by the hosting
application and reduces the occurrence of new elections and
re-registration. The registry process should by default exit
some time (10-60 sec.) after the last app has de-registered.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=75003
Added a file containing some general
thoughts about such a registry.
Thoughts about the registry.
Logged In: YES
user_id=15949
1. with regards to the 'suppress the auto-dectection to
prevent spawning of infinite number of processes' - isn't
this "just" a simple lock of some sort - perhaps an open
socket - that gets released at the appropriate times?
2. what would be the use of comm send without registry?
3. Re: communicating via an environment variable - how about
through the Tcl option database or something? Environment
variables are nasty as they require user intervention - this
mechanism to be transparent needs some other method.
4. It sure would be useful if the resulting mechanism was be
able to support, when needed, cross-machine comm send - so
that multi-user internet apps could be built on the
structure.
Logged In: YES
user_id=75003
Ad 1. The scenario I saw was the startup of the registry
immediately upon loading comm. As the registry needs comm
itself comm starts the registry before the registry opened
its server socket. So comm when loaded by the registry does
not find the registry and thus tries to start it again, ad
infinitum. With the current model of starting the registry
only when it is accessed for the first time this cannot
happen as the registry needs comm, but not the part about
accessing the registry itself. Reinhard Max's scenario of
the first application automatically acting as the registry
itself does not have this problem either.
Ad 2. Applications which are coded to know about each other
by some other means. For example an application launching a
child and explicitly telling it on the command line where
to find the parent.
Ad 3. What we need for the scenario is some means of
automatically sharing this information. I don't believe
that the tcl option database can do this. Or do you mean
about setting and querying the option database on an X
server ? Do we have code to do this ? About the user
intervention bit. As this is about an application and its
child processes the environment is passed automatically
without user intervention. ... Ok, the per-user setup
requires work from the user.
Ad 4. comm itself automatically support cross-machine send,
as the hostname is part of the communication handle, and
not only the port to talk to. So we only need a way for
cross-machine registries. A proxy would be a more safe way
IMHO than directly talking to a remote registry. The proxy
can for example to encryption without burdening the local
applications with this task.
Reinhard Max proposed that the first application able to
open the listening socket should automatically act as the
server. If it goes away for wahtever reason one the other
applications opens the socket and starts to act as
registry, with the other applications reregistering.
Another proposal of his is to include a notification
mechanism so that applications can get events if other
applications (de)register. Using that all applications
could maintain a local copy of the registry.
Logged In: YES
user_id=75003
Enclosed a file with more thoughts incorporating the
discussion below.
Thoughts, second round
Logged In: YES
user_id=124643
I'd like to modify my proposal (one of the applications
becomes the registry server) a little bit. Instead of acting
itself as registry, an application should start a separate
registry process in the background, if it won the election.
This prevents the registry from being blocked by the hosting
application and reduces the occurrence of new elections and
re-registration. The registry process should by default exit
some time (10-60 sec.) after the last app has de-registered.
Manpage for a registry config package (doctools format)
Logged In: YES
user_id=75003
Added a manpage in doctools format describing a possible
API for a registry configuration package. Not for the
registry query functionality itself.
Logged In: YES
user_id=75003
Originator: NO
While not really automatic the 'nns' module (nano-nameserver) is step towards this.
zzzzzz