Re: [Pengfork-devel] Work state

[Jean-Charles Salzeber]

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:
> 
> Ok, that's what I deduced, but in this case, in the function, when you do 
> place your header and data pointer at buffer_end(), how are you sure you will 
> have enough pre-allocated space ?
It isn't :)
buffer_alloc have to be changed to take in account this fact.

In fact, currently this is not ambarassing, the buffer is quite BIG,
this can become dangerous only when TCP/IP will work.

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

> 
> >   + 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.

> 
> > But if we plan to make a 'pengctl',a gui program where will we put them?
> > as separate modules?
> 
> I see 2 choices :
> 
> 1) Include them in pengfork hierarchy this way :
>   + pengfork/
>      + src/ ==> pengfork core src
>      + pengctl/
>         + src/
>      + pengui/
>         + src/
> 
> This way we consider pengfork as the main binary, and pengctl and pengui as 
> sattelite programs.
> 
> 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.
So currently I'm thinking of 3 possible different modules: pengfork(with 
pengctl), pengui, and pengtools(mail, ...)

Feedback?

> -- 
> Nicolas

JC

pgp8G0o_wCeSm.pgp
Description: PGP signature