pengfork-devel
[Top][All Lists]
Advanced

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

Re: [Pengfork-devel] Improvements


From: Nicolas Burrus
Subject: Re: [Pengfork-devel] Improvements
Date: Wed, 21 Aug 2002 23:20:48 +0200
User-agent: KMail/1.4.3

On Wednesday 21 August 2002 19:47, Jean-Charles Salzeber wrote:
> On Tue, Aug 20, 2002 at 13:28, Nicolas Burrus wrote:
> > Hello, I think I'm inaugurating this mailing list :)
>
> Hi Nicolas!
> Right, you're the very first one :)
> Thanks for starting the conversation.
>
> > Since the projects seems to have a new start, I have some features
> > suggestions (I have already done partially some of them in my hacked
> > version of pengaol 1.0 beta) :
>
> I'm also working on a new version... but I'm reimplementing it from
> scratch. I use C for it ,not for political reason, but I think peng should
> be in C because:
>   1) there are more C developpers than C++
>   2) peng use many low-level functions (interface handling, i/o functions,
> ...) 3) C is more portable
>   4) pppd and similars programs use C, why not peng!?
>   5) ... ?

I have nothing against C :) I think too it is a better langage for this kind 
of application, I just didn't know you wanted to rewrite all from scratch, 
but it's a good idea, I think the only really good things to extract for 
pengaol is the AOL protocol, compression, etc ... but it needs a complete 
rebuild.

BTW, the portability problems won't mainly come from the language I think (c++ 
is quite portable), but from the OS's particularity with low level system 
calls ...

> > Clean up the code
> > =============
> >
> > 1) Indentation is awful, maybe should use GNU coding style ?
> >
> > 2) Many things are in hard in the code, such as configuration files path,
> > etc ... it should be set by the configure scripts.
> >
> > 3) C-style syntax for I/O, it is c++, so it should use std::cout, etc ...
> > instead of C printf. Same things for list, stl lists are more adapted.
> >
> > 4) Command line options parsing : would be better and more standard with
> > getopt.
> >
> > 5) Use autoconf & automake exclusively, I don't see the utility of the
> > recompile script ! ./configure --prefix=/opt/pengaol-1.0 && make && make
> > install should work and install binaries in /opt/pengaol-1.0/bin.
> >
> > 6) Comments should be in english everywhere.
> >
> > 7) Clean up logging messages, add syslog handling, etc ...
> >
> > 8) Clean the source tree, directories are not well chosen I think,
> > peng/peng for the sources should be peng/src for example.
> >
> > 9) Make pengui a separated projects, maybe a subdirectory, I think most
> > people want a light version of pengaol by default.
>
> Agree with all your suggestions.
> I would add that we should use:
>   * gettext for internationalization
>   * In general, POSIX compliant stuff
>   * A better/more complete configuration file

Nice !

> I think a third-party 'pengctl' program could be used to disconnect.
> This program could also start peng, have some statistics information, and
> could be used to control peng with the GUI and eventually others
> third-party programs like an email/newgroups/... wrapper.

Ok, why not, it would be nice.

An idea just come to me, would it be possible to make a kernel module 
implementing the AOL ppp protocol, and then use pengaol as an higher level 
program interfacing modem, cable, etc ... with this driver ? I'm not familiar 
at all with kernel ppp stuff, so my idea is certainly impracticable, but I 
think it merits some investigation, isn't it ? And in this case, is it 
impossible to use pppd, maybe with a little patch ?

PS: I have some trouble with my mail server, hope you won't receive the mail 
twice.

-- 
Nicolas Burrus





reply via email to

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