[Fwd: Vgetty question]

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

Hi,

just a few notes on this:

On Mon, Jun 21, 1999 at 05:49:55PM +0000, Vandoorselaere Yoann wrote:
[..]
> Excuse me for what i will say,
> but vgetty seems to be a software written without thinking to it's
> internal design before writing piece of code...

Marc Eberhard spent a huge lot of time designing this.  Modem programming
*is* messy, so the resulting programs are not always "straightforward".

> So what i'd like to say is :
> All modem driver are in a library... ( libvoice.a which depend on other
> librarie...
> I was trying to reuse it... it was a pain... so i've started to write an
> other library
> using piece of your code )...

Actually I think this is a good design.  You have low level functions
(tio.o, locks.o, logfile.o - they could be in a library, but I didn't do
that for portability), mid level functions (libvoice.a) and high level
programs (vgetty, vm).  How would you do this differently?

> Why didn't you use module for modem driver: it save lot of memory...
> Why AT command for a given modem can't be added by an end user in a text
> file...
> ( without editing the sources )

No, you can't do that.  The differences are not only the different AT
commands, but sometimes the actual flow of control is different (read: you
have to act in a completely different way for certain modems, especially
to work around certain modem bugs).

If modems are "similar", they usually share lots of code already anyway,
like all the IS-101 based modems.

> Why didn't you use standard file locking ?

What do you mean by this?  The only place mgetty/vgetty does "file
locking" is for the serial port, and there is only one "standard" way to
do that - using LCK..ttySx files, and this is what locks.o is doing.

> Why doesn't you act as a server which could serve other applications
> using modem
> ( and no, this is not off topic because vgetty is, as far as i know, the
> only software
> which has driver for several modem... )

This can be done using the "vm shell" interface - you have the "server"
(vm) and the "client" (the voice shell), they talk to each other, and the
client can use vm to talk to the modem.  What are you missing?

[..]
> >From my point of view,
> vgetty should listen on a given port,
> waiting for an applications to connect and passes it command...
> It should notify the application when it receive a RING...
> ...

You're thinking Windows here.  Vgetty is a *server* process, there can be
dozens of different vgetty processes running on different modems, and you
don't want to see them.

If you want a GUI, use "vm", and talk through vm with the modem.  If
you're missing functions, tell us.

[..]
> No !!!
> I'm a C coder...
> I don't want to make exec call to vm...
> I hate frontend...

Where's the difference between "make an exec call / talk to a pipe" and
"make a socket call and have inetd exec() a server process"?

You're talking nonsense.

[..]
> Eg :
> with a realtek based voice modem :
> 
> at#cls=8
> at#vls=6
> ata

Hmmm.  Why do you want to use vgetty for that *at all*?  You're not using
any of vgetty's capabilities, and sending three AT commands to the modem
is pretty easy...  I don' think vgetty is the right approach for *this*.

[..]
> But this is what I ( and many end user too ) want to devellop...
> Yes voice frame are currently supported  ( send & receive at the same
> time )!!!
> This is not complicated,
> You use the modem LOCAL HANDSET to communicate on the phone line...
> ( Not the sound card )...

You're not doing "bidirectional voice communication" (using vgetty),
you're doing "send a few AT commands to the modem, and then do nothing at
all" (non-directional voice communication :) ).

What you want doesn't need vgetty's power, "chat" can do it just fine.

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