[freeside-devel] Some Ideas

[Jason Thomas]

Hi All,

I've been evaluating FreeSide for the company I work for, and as I'm a
Debian developer I had a go at packaging it up for Debian.

Well to put it bluntly things look to be a mess. Which explains why it
took Richard Siddall 6 months to create redhat packages.
http://www.sisd.com/pipermail/freeside-devel/2005-September/000521.html


Anyway, so I've written down some ideas which should help spur some
developement work on FreeSide and maybe even new users. Hopefully this
will lead to packagable product for Debian/Redhat/<insert distro>.

So below is the list, I'm not at all experienced with FreeSide, so if
there is anything dumb just say so or ignore it.

Thanks.


IDEAS
=====

 * Split freeside into nicely defined parts (which can still be in the same
   tarball):
	- fs
	- fs docs
	- fs web interface
	- fs self service server
	- fs self service client
	- fs modules; radius, bind, postfix, sendmail, apache, etc

 * Use autoconf in each part, so that various configuration options can be
   changed easily, like install directories. AutoMake can be used to substitute
   paths in perl scripts and modules.

 * There can still be a single Makefile in the base of the directory structure
   to make it easy for people use to the current install method.

 * Each part should not rely on others. This is so that the web interface or
   self service server could be run on another machine.

 * The web interface should not need to run as the freeside user.

 * If we make freeside self service server a module than other modules can be
   written. Or perhaps we can write an some sort of socket based API with which
   to interact with freeside.
 
 * A clearly seperate web interface would make it easier for people to write
   there own, or for us to have more than one. Perhaps we could use some sort
   of templating system.

 * The configuration files should be cleaned up. why so many dirs. Let use
   something familiar look INI files.
 
 * DB choice should be in the config file. The name of the DB shouldn't have
   anything todo with the other config files.
 
 * Each part should have its own config file. The minimum in each config would
   probably be database info.

 * All paths should be configurable in the config file, and use sensible
   defaults. e.g logging to log/freeside instead of etc/freeside/

 * Logging probably should use syslog or at least be configurable. There is a
   perl module for that.

 * handler.pl where should that go, not etc/freeside/

 * Template path should be in config file.

 * Provide example web server conf files.

 * Pages in web interface should be split into multiple pages, instead of one
   big long page.
 
 * It would be cool if freeside could be neutral when it comes to things like
   DNS. So you store DNS entries but there not specific to bind. Then we could
   have some sort of module to populate bind. Same with mail softwarei and
   radius. etc. Like modular I suppose.