Tk Library Source Code

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.

Logged In: YES 
user_id=75003
Originator: NO

While not really automatic the 'nns' module (nano-nameserver) is step towards this.
zzzzzz

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.

File Added - 14825: registry.man

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.

File Added - 13777: registry

Logged In: YES 
user_id=75003

Enclosed a file with more thoughts incorporating the
discussion below.

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=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.

File Added - 13555: registry

Logged In: YES 
user_id=75003

Added a file containing some general
thoughts about such a registry.