There happen to be an existing candidate for extensions to handle diald
-
linuxconf, which already supports plug in
management modules, and text mode, X windows, and HTTP access
UI's.
It is currently weak in PPP support generally - it can configure multiple
manually activated dial-outs, but does not allow one to give them meaningful
names; it will enable diald at start-up, but only one instance; and
so far I
have been unable to pursuade it to configure dial-in PPP accounts (I
get the error
message "must be selected from list" but what and from what list is
not explained).
I believe most people setting up Linux start here. Maybe someone should
investigate
further...
Management:
Essential tools: a mailing list for participants, with periodic status
updates to this
list; 24/7 access to a cvs tree, and IMHO a WikiWiki site (I use
TWiki
- a web based collaboration tool ) which also needs 24/7. Unfortunately
I cannot offer 24/7 myself at this time. And. of course, a release
Czar.
Features: see my next missive for an example complex setup, with caveats.
Cheers!
David Warman
Paul Leon wrote:
As I have said before, I'm not experienced in application development....My two bits ?
Keep the discussion of pro's and con's going... best if we choose a language / platform
(Java, C, C++, etc.) for all of the right reasons.>From the looks of it, it seems that there's interest in creating such an app, and people
willing to put their blood, sweat and tears into successfully completing it. We should
start spec'n out what the program will do and how it will do it... features... while still
debating what language / platform to develop on... So this is where talk turns into
action...It would be more productive if someone / people that is experienced with application
development starts managing this project. I want to be apart of this project, so I'm gain
to start pitching in...I'll be writing down specifics on what I would like diald to do / have and I will be
mailing it out to the list by Monday (rough week...), others have expressed their needs
for the program, so I'll start compiling the wish list and include it..., feel free to
send your two bits to the list / wish list...Cheers,
Paul LeonCary O'Brien wrote:
> 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]-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
--
Dave Warman
====================================================
Warman's First Law:
Everything that can be configured, must be
Corollary:
Defaults aren't
