Now that idea makes a lot of sense.
-----Original Message-----
From: David Warman
Sent: Wednesday, June 23, 1999 2:46 AM
To: LKLawson; Paul Leon
Cc: 'LINUX-DI@SMTP <[EMAIL PROTECTED]>'
Subject: Re: GUI for Diald
My two bits:
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 Leon
>
> Cary 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
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#CCFFFF" link="#0000EE" vlink="#551A8B"
alink="#FF0000">
My two bits:
<p>There happen to be an existing candidate for extensions to handle
diald
-
<br>linuxconf, which already supports plug in
<br>management modules, and text mode, X windows, and HTTP access
UI's.
<br>It is currently weak in PPP support generally - it can configure
multiple
<br>manually activated dial-outs, but does not allow one to give them
meaningful
<br>names; it will enable diald at start-up, but only one instance; and
so far I
<br>have been unable to pursuade it to configure dial-in PPP accounts (I
get the error
<br>message "must be selected from list" but what and from what list is
not explained).
<br>I believe most people setting up Linux start here. Maybe someone
should
investigate
<br>further...
<p>Management:
<br>Essential tools: a mailing list for participants, with periodic
status
updates to this
<br>list; 24/7 access to a cvs tree, and IMHO a WikiWiki site (I use
<br> <a
href="http://www.mindspring.net/~peterthoeny/twiki/index.html">TWiki
- a web based collaboration tool</a> ) which also needs 24/7.
Unfortunately
<br>I cannot offer 24/7 myself at this time. And. of course, a release
Czar.
<p>Features: see my next missive for an example complex setup, with
caveats.
<br>
<p>Cheers!
<p>David Warman
<br>
<p>Paul Leon wrote:
<blockquote TYPE=CITE>As I have said before, I'm not experienced in
application
development....
<p>My two bits ?
<p>Keep the discussion of pro's and con's going... best if we choose a
language / platform
<br>(Java, C, C++, etc.) for all of the right reasons.
<p>>From the looks of it, it seems that there's interest in creating such
an app, and people
<br>willing to put their blood, sweat and tears into successfully
completing
it. We should
<br>start spec'n out what the program will do and how it will do it...
features... while still
<br>debating what language / platform to develop on... So this is where
talk turns into
<br>action...
<p>It would be more productive if someone / people that is experienced
with application
<br>development starts managing this project. I want to be apart
of this project, so I'm gain
<br>to start pitching in...
<p>I'll be writing down specifics on what I would like diald to do / have
and I will be
<br>mailing it out to the list by Monday (rough week...), others have
expressed
their needs
<br>for the program, so I'll start compiling the wish list and include
it..., feel free to
<br>send your two bits to the list / wish list...
<p>Cheers,
<br>Paul Leon
<p>Cary O'Brien wrote:
<p>> One small observation:
<br>>
<br>> Are you *sure* spending time on a gui configuration tool is the
best
<br>> expenditure of time and energy. Consider an alternative --
a shell
<br>> script that audits a diald configuration, points out possible
problems,
<br>> and asks for input when necessary. Time spent fiddling with
listboxes
<br>> could be spend writing better diagnostics for the many, many
configuration
<br>> problems we see on the list.
<br>>
<br>> Think about something like autoconf for diald, except with a
slightly
<br>> less hostile interface.
<br>>
<br>> Just an idea.
<br>>
<br>> More comments below.
<br>>
<br>> > Steve Dicks wrote:
<br>> >
<br>> > > On Fri, 18 Jun 1999 10:56:34 -0700, [EMAIL PROTECTED] said:
<br>> > >
<br>> > > > I would rather see it in GTK++, or Qt before java.
<br>> > > > Its not like this program would ever be used in Windows or
Mac, so why does
<br>> > > > it need to be in Java?
<br>> > >
<br>> > > Really? Personally I use my Linux box as a pure headless
server,
and administer
<br>> > > it via both Win95 and Acorn RiscOS. So Java is the obvious
choice
- multi-platform
<br>> > > without even thinking about it.
<br>> >
<br>> > I do too, which means my access program of preference is my
browser.
So the
<br>> > language of choice is whatever will run on Linux and talk HTTP.
So it's CGI.
<br>> >
<br>> > On a higher level, it is pretty clear that the typical diald app
is on a small
<br>> > home network with Winxx clients and Linux Internet access server,
so presumably
<br>> > this will be the first target. However, I have a plea for the
brave
soul who
<br>> > embarks on this - leave the door open for more complex
applications.
I have
<br>> > just spent 30-40 hrs getting a three-site setup working. None
have
permament
<br>> > Internet connections. All have Win95, Win98, WinNT, and Mac
clients.
<br>> > Site A is the hub, has an ISDN router out on the Ethernet plus
a modem. Site B is the
<br>> > simplest and only call site A, no masquerading. Site C has his
own Internet
<br>> > account, and only the one modem. I finally got it so A can call
B or C, B can
<br>> > call A, and C can call A or his ISP. When B or C is connected to
A, regardless
<br>> > of who placed the call, they also get masqueraded out to the
Internet
through
<br>> > site A's ISDN router. All calling is initiated automagically by
the attempt to send
<br>> > a packet. I needed this complexity because I am managing all
three
sites
<br>> > (A is home) plus running collaboration tools on all three. The
major problem,
<br>> > and only partially solved so far, is what happens to DNS
inquiries
at site C
<br>> > while it is dialling site A.
<br>> >
<br>>
<br>> Wow. I haven't gotten beyond 2 dialds on one machine or two
diald machines
<br>> one one network. And I still don't have a local DNS server.
<br>>
<br>> > My dream GUI would handle all this, plus I could install it now
and it would
<br>> > just read my config files and go, so I could if necessary use it
to add
<br>> > a fourth site like C to the family.
<br>> >
<br>> > If anybody is interested, I could post how this scheme finally
worked.
<br>> >
<br>>
<br>> Why not write it up for "The Linux Journal"? I wrote a tiny
article a year
<br>> and a half ago, and they still send me 5 copies a month, allowing
me to
<br>> slowly infiltrate MS bastions.
<br>>
<br>> Hmmmm. Not sure what a LJ article about diald would do to the
list.
<br>>
<br>> -- cary
<br>>
<br>> -
<br>> To unsubscribe from this list: send the line "unsubscribe
linux-diald"
in
<br>> the body of a message to [EMAIL PROTECTED]
<p>-
<br>To unsubscribe from this list: send the line "unsubscribe
linux-diald"
in
<br>the body of a message to [EMAIL PROTECTED]</blockquote>
<p>--
<br>Dave Warman
<br>====================================================
<br>Warman's First Law:
<br> Everything that can be configured, must be
<br>Corollary:
<br> Defaults aren't
<br>
</body>
</html>
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
