Re: [Pengfork-devel] Work state

[Nicolas Burrus]

On Monday 26 August 2002 10:07, Jean-Charles Salzeber wrote:
> On Mon, Aug 26, 2002 at 00:40, Nicolas Burrus wrote:
> > On Monday 26 August 2002 00:02, Jean-Charles Salzeber wrote:
> > > On Sun, Aug 25, 2002 at 22:29, Nicolas Burrus wrote:
> > > > Will the code be imported in CVS soon ?
> > >
> > > Currently my directory structure is:
> > > pengfork
> > >   + include
> >
> > I don't really like a separated include dir (for editing and searching
> > reasons), but it is totally personnal, so if you like it, it's ok with
> > me.
>
> This have sense when there are several programs accessing common headers.

'k

> > >   + src
> > >       + linux
> > >       + openbsd
> > >       + freebsd
> >
> > 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 ?

> > > But if we plan to make a 'pengctl',a gui program where will we put
> > > them? as separate modules?
> >
> > I see 2 choices :
> > [...]
> > 2) Make them separated projects
> >   I like modularizing projects :) The 3 parts does not seem to need
> > sharing source code, so why not creating 3 separated entities, with maybe
> > a tarball which contains the 3 parts when doing a release ?
>
> I think there is a misunderstanding, I was talking of 'cvs modules'.
> But unlike you, I think some headers will be shared among modules.
> I think pengctl is an exception, because users will always want to build
> it. I think it's better to keep it with the core project.
>
> > 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 ?

> 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 ?

-- 
Nicolas