pengfork-devel
[Top][All Lists]
Advanced

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

Re: [Pengfork-devel] Work state


From: Jean-Charles Salzeber
Subject: Re: [Pengfork-devel] Work state
Date: Mon, 26 Aug 2002 11:26:16 +0200
User-agent: Mutt/1.5.1i

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:
> 
> > > Hum, do you really need one directory by architecture ?
> >
> > Well, currently I used this because tun implementation is different on
> > each platform. I'm sure some others low-level functions will need
> > complete reimplementation on each platform.
> 
> So src will have most of the sources files, and in each arch directory there 
> will be only specific sources files ?

Exactly.

> > > I prefer solution 2), which create more separated modules, does not
> > > oblige the user to download the 3 parts, does not highlight one
> > > particular GUI among others (there may be several guis by different
> > > people one day :). It also permits multiple extensions without making the
> > > main project heavier.
> >
> > Sure! There are many extensions possible for hard-working people. All
> > what the AOL interface does is possible (except memory consuming, timer
> >
> > :). I believe all this function are just more codes that you find in
> >
> > p30data.h . So I can imagine mail, newsgroup, account management,
> > billing info, aim, etc... communicating with the core peng with a
> > defined interface.
> > So we will need some common headers, but this is not a real problem,
> > this headers will not change much in the time, so we can copy them among
> > modules.
> 
> But we'll need a communication library in fact, which would be used by all 
> external programs, isn't it ?

I was not thinking of that but it's a good idea.

> 
> > So currently I'm thinking of 3 possible different modules: pengfork(with
> > pengctl), pengui, and pengtools(mail, ...)
> 
> Ok, I had not well understood your point of view, I agree with you. 
> 
> 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.

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.

> -- 
> Nicolas

JC

Attachment: pgpWVFO54pFu3.pgp
Description: PGP signature


reply via email to

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