>> proftpd-1.3.2-0.4.rc3.fc11.i586.rpm (info) (download)
>> proftpd-ldap-1.3.2-0.4.rc3.fc11.i586.rpm (info) (download)
>> proftpd-mysql-1.3.2-0.4.rc3.fc11.i586.rpm (info) (download)
>> proftpd-postgresql-1.3.2-0.4.rc3.fc11.i586.rpm (info) (download)
> Again, I'm not sure how this makes it much easier for people packaging.
> Even if you went with the module system, you'd have to compile each
> module seperately.  The packages above, even at the very least, provide
> a new module.  The same could be done by ./configure
> --enable-auth-module=x
> && make.

The trick here is that by separating out the back-end authentication
schemes into modules, you can provide a single source build for package
maintainers, which will generate multiple component packages for the whole
setup.  Then they don't have to maintain separately configured source
trees and builds for each authentication module, but can do a single build
that can be configured at runtime to use any available (i.e., installed)
module.  The user then can install just the module(s) that they want and
configure them at will without having to uninstall and then install the
new package.

> If you were to provide authentication packages for vpopmail, they'd
> replace
> libvpopmail and the binaries.  For the 5.5 tree, you can link against the
> shared object files if you choose to as well, meaning packages would only
> need to replace libvpopmail.so, or even just a symlink to a different
> library.
Again, the authentication modules would be removed from libvpopmail.so,
and libvpopmail.so would load the appropriate library (e.g.
libvpopmail_<authtype>.so) based on the vpopmail configuration.

> Modules are not out of the question, but I'm not shooting for them in the
> near
> future.  vpopmail as a project just doesn't need them very badly right
> now.
I think that depends on the direction that you want to take vpopmail in. 
If you're just aiming to update the code, fix bugs, and add needed
functionality, then you're probably right.  If you're looking to expand
the scope of vpopmail usage and deployments (which binary packages will
inevitably do as users who don't want to custom-compile things start
making use of it), then modularizing the authentication systems is
probably the second most important thing to do, after fixing any bugs that
might be lurking in the code right now, especially in the back-ends.

Also, by creating a modular vpopmail-backend API, you could even break the
authentication components out of the vpopmail code tree so that other
people could easily maintain and even add new back-end support.  Again, I
don't know what your goal is, so that will certainly influence how you
want to prioritize things.

> If someone wants to write a patch against the 5.5 tree, I'll look into it
> and
> if the code is done well, I will consider adding it, but it was not in my
> plan
> for 5.5.

Fair enough.  I can't remember if you've done it or not, but if you
haven't you might want to consider posting a to-do/wish list/roadmap for
vpopmail development so that people can assist with and/or comment on
where things are going.  Thanks for working to make vpopmail better!


Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
  - Layman's translation of the Laws of Thermodynamics


Reply via email to