pengfork-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pengfork-devel] Work state


From: Nicolas Burrus
Subject: Re: [Pengfork-devel] Work state
Date: Mon, 26 Aug 2002 11:47:40 +0200
User-agent: KMail/1.4.3

On Monday 26 August 2002 11:26, Jean-Charles Salzeber wrote:
> On Mon, Aug 26, 2002 at 10:44, Nicolas Burrus wrote:
> > On Monday 26 August 2002 10:07, Jean-Charles Salzeber wrote:
> > > On Mon, Aug 26, 2002 at 00:40, Nicolas Burrus wrote:
> >
> > I wonder if it is possible to have a library implementing AOL protocol,
> > packet construction functions, etc ... and have pengfork binary handling
> > modem driver, tun, etc  ... It would allow developping other connexion
> > clients without having to integrate aol protocol, but just reusing
> > existing one. What do you think ?
>
> In my mind the gui is just a frontend launching other programs, no
> matter what protocol they use.

Erf, I was not speaking about GUI's actually, but real connexion client, I 
mean, another programs with modem drivers, tun, etc ... In fact I was talking 
about dividing the peng program in a lib with the protocol and a binary with 
modem/tun drivers which use this library. I think it can be interesting to 
have the AOL protocol a separate thing, very portable and reusable.

> For others programs they must communicate with the core peng.
> They must register what code they use and send, so that peng will know
> who handle this code and send recevied data to this program. This can be
> done with socket/fifo/IPC/RPC.
>
> In fact we could do this with TCP/IP tunneling, but for performance
> reason it's a bad idea.
> The modem *AND* the low level protocol (called P3 by birdy) must be kept
> inside the peng program (tun is part of TCP/IP tunneling 'module').
> But the work of p30data.c could be to find a registered program that
> handle a received code and send the data to him, or permit him to send
> data.
>
> I don't know if I'm really clear but it's a bit early to talk about
> that, we're currently far from from this point.

Right, let's see that later, it doesn't matter for the moment :)

-- 
Nicolas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]