[Fwd: Vgetty question]

• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi,

On Tue, Jun 22, 1999 at 07:41:26PM +0200, Steffen Klupsch wrote:
> Vandoorselaere Yoann wrote:
> > I think it could be really improved if we rewrite it, but this time
> Hmm, let's start doing some extensions..

Let's avoid doing Yet Another Rewrite before the last one has stabilized.

What you see in 1.1.x is already the Much Imrpoved Rewritten code, and you
wouldn't know how tricky it is to get the "workarounds for each vendor's
modem bugs" right.

> > ( Feature: modem are defined at compile time, use text file for that,

This wouldn't change much soon.  Voice modems *basically* are very simple,
but the workarounds for modem bugs are too numerous to be able to describe
this in text files (or you have so much overhead to read the complete
program logic from the text file...).

Also, this wouldn't necessarily stabilize anything - let's work on getting
individual modem drivers robust, even in the face of all the modem bugs,
and in parallel let's add new high-level features, but no low-level
rewrite now.

> I need more information about this feature. As I see the actual status
> is as follows: vgetty is compiled without knowing which modem is used -
> and can work with all of them (Plug and play!!). If problems occur you
> can specify modem workarounds using a config file (text) which is read
> during startup of the program. What is missing?

If you add a new modem type (because some modem is slightly different from
others from the same company, etc) you have to change the source code.
This is awkward, but all other solutions are worse.

Mgetty (not vgetty) will be changed in future so that the "easy things"
(like "init string", "known fax issues", ...) can be auto-configured
via a file containing modem ID codes and "flag settings".  Basically an
runtime extendable extention to the auto-configuration mechanism that's
already there - similar to Netblazer's "modemcap.txt".

> > support bidirectionnal communication through the modem... )
> > > 'bidirectionnal communication through the modem'
> > > You might be talking of 'chating' using the modem mic and the modem
> > > speaker.
> > Exactly...
> 
> 
> OK. I vote for that too. You request an extension of
> libvoice/*.c/*_set_device(int device) so that 'device' includes 
> 'SPEAKER_PHONE_MODE' or 'LOCAL_HANDSET' for all modems.

Not all modems can do this, but if they do, we should be able to support
it.  Feel free to add this to the low-level driver for your modem and send
us patches for it.  Please understand that we can't change drivers for
modems that we don't own, and thus can't test.

> Hi Marc, is it possible this is already realized in some libvoice/*.c
> files?
> Perhaps someone could add some more error messages for the log file in
> cases the desired mode is not available. I am going to do that for UMC.c

Detailed log messages are always a very good idea.

> Is there an example on how to use set_device from within a script?

Uh.  Can't answer this (I'm the "mgetty plus strategy" man :-) ).

[..]
> > We can't share more than one process on a tty,
> That's not your problem. Vgetty frees the tty as soon as the modem init
> succeded, you can use another process to do outgoing-calls (Your point
> 2).

*IFF* the outgoing call program does proper device locking.

> > but feature like a library for another program to use vgetty to pass
> > data to the modem (
> > vgetty get locked when a library function is called ) could really be
> > usefull...
> > ( And i think that an client server arch could be even more )
> But it might be a hard bit of work :-(

I'm not sure why people always think "client server" is a good thing...  :-)

Anyway - making a C interface to vgetty would be doable, maybe using the
"shell / pipeline" interface, maybe using the internal libvoice stuff.

But someone has to do it...  and that's not Marc and not I.

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert@greenie.muc.de
fax: +49-89-35655025                        gert.doering@physik.tu-muenchen.de