For Plan 9 you could use either version of adsrv. The one in sources is centralized, and behaves similar to a registry. The one in our dumb (probably in sources dump as well) was a distributed one (no longer in production use).
For the octopus I think I copied a modified registry that knows how to report changes to blocked readers. In case I didn't, assuming anyone might want such thing, just drop us a line. On 9/13/07, Eric Van Hensbergen <[EMAIL PROTECTED]> wrote: > On 9/13/07, Enrico Weigelt <[EMAIL PROTECTED]> wrote: > > > > while thinking about my plans for using 9P servers in numerious > > situations I just realized that server management can become > > quite complex. > > > > For example if an application like mozilla would move out many > > jobs (ie. like currently discussing @ mozilla.org: rss-feeds), > > server management can be quite complicated. We can't expect > > neither the user nor the individual application to be responsible > > for that. We need some zero-configuration approach. > > > > Actually it can be done by another server, which knows about > > all the individual servers, handles startup/shutdown and tells > > the clients where to find them, how to authenticate, etc, etc. > > A little bit like RPC portmap. > > > > What do you think about this idea ? > > > > While going with something "standard" (but a bit sticky) like zeroconf > may be attractive, you may want to look at what the Plan B guys did -- > IIRC they have network discovery and organization integrated into > their basic framework. > > Essentially I think it makes the most sense to work this sort of > auto-discovery into existing services (ndb/cs for instance). > Accomodating zeroconf as a protocol would be nice (particularly from a > cross-platform compatibility angle), but you could also do something > like Inferno's registry. > > -eric >
