One small observation:
Are you *sure* spending time on a gui configuration tool is the best
expenditure of time and energy. Consider an alternative -- a shell
script that audits a diald configuration, points out possible problems,
and asks for input when necessary. Time spent fiddling with listboxes
could be spend writing better diagnostics for the many, many configuration
problems we see on the list.
Think about something like autoconf for diald, except with a slightly
less hostile interface.
Just an idea.
More comments below.
> Steve Dicks wrote:
>
> > On Fri, 18 Jun 1999 10:56:34 -0700, [EMAIL PROTECTED] said:
> >
> > > I would rather see it in GTK++, or Qt before java.
> > > Its not like this program would ever be used in Windows or Mac, so why does
> > > it need to be in Java?
> >
> > Really? Personally I use my Linux box as a pure headless server, and administer
> > it via both Win95 and Acorn RiscOS. So Java is the obvious choice - multi-platform
> > without even thinking about it.
>
> I do too, which means my access program of preference is my browser. So the
> language of choice is whatever will run on Linux and talk HTTP. So it's CGI.
>
> On a higher level, it is pretty clear that the typical diald app is on a small
> home network with Winxx clients and Linux Internet access server, so presumably
> this will be the first target. However, I have a plea for the brave soul who
> embarks on this - leave the door open for more complex applications. I have
> just spent 30-40 hrs getting a three-site setup working. None have permament
> Internet connections. All have Win95, Win98, WinNT, and Mac clients.
> Site A is the hub, has an ISDN router out on the Ethernet plus a modem. Site B is the
> simplest and only call site A, no masquerading. Site C has his own Internet
> account, and only the one modem. I finally got it so A can call B or C, B can
> call A, and C can call A or his ISP. When B or C is connected to A, regardless
> of who placed the call, they also get masqueraded out to the Internet through
> site A's ISDN router. All calling is initiated automagically by the attempt to send
> a packet. I needed this complexity because I am managing all three sites
> (A is home) plus running collaboration tools on all three. The major problem,
> and only partially solved so far, is what happens to DNS inquiries at site C
> while it is dialling site A.
>
Wow. I haven't gotten beyond 2 dialds on one machine or two diald machines
one one network. And I still don't have a local DNS server.
> My dream GUI would handle all this, plus I could install it now and it would
> just read my config files and go, so I could if necessary use it to add
> a fourth site like C to the family.
>
> If anybody is interested, I could post how this scheme finally worked.
>
Why not write it up for "The Linux Journal"? I wrote a tiny article a year
and a half ago, and they still send me 5 copies a month, allowing me to
slowly infiltrate MS bastions.
Hmmmm. Not sure what a LJ article about diald would do to the list.
-- cary
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
