"Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx> wrote: > > I think the deskbar replicant should be optional anyway (also for > > dial-on-demand). And your local intranet replicant doesn't sound > > like a DUN connection. > This intranet is a dial-up connection to your company's or > university's > private network (i.e.: you get access to the private servers by > dialing > the company's telephone number with a modem). I see :) > > Technically, if you want to have more than one replicant in the > > deskbar you need either several binaries, or you have one > > running application that adds these. > I would prefer having the possibility to run multiple connections > (only > one replicant would not show which interface is currently sending > data > with the transfer indicators (e.g.: blinking monitors or arrows)). I think using a background application is then the preferred way to do it (even if it doesn't have to run all the time, but only on demand). > > IMO something like inetd would be a good place for functionality > > like > > this (or whatever we'll call it). It could also (optionally) > > display > > the link status in the Deskbar, the connection speed, etc. > If our inetd will support add-ons so there is no PPP-specific code in > it this is a possible solution, too. What I need is a background > process that watches all interface description files and connections. What do you think about my suggestion in the other mail on this topic? Having one net_server in userland that manages all of this seems to make sense for me. When the stack is built for userland, we would just have a net_stack and a net_server running side by side :) Bye, Axel.