Henrik Nordstrom wrote: (snip)
> a) Getting the APIs the modules needs to use to perform their actions > reasonably in shape. > > b) Adding suitable component registries, allowing modules to register at > runtime and avoiding direct knowledge of the implementation in other > parts of the code. > > > 'a' is quite important if we are to open for third-party modules as > there is then a need for a reasonably stable API the modules can use. > It's not going to be seen well if key aspects of those APIs changes > every month.. I think you don't need to burn your brains too much on this point. Figuring the perfect API out of the blue could mean spend a lot of energies on something that would eventually freeze anyway, and if one really needs a feature that was introduced few hours before, he won't complain if minimal adjustments are required for a while (he'll probably have more issues within his own plugin). Having said this, your point definitely makes sense, and should drive the design, but without excessive concern. > but for the goal of spliting Squid in loadable objects all under our > control then it's not so important and just 'b' suffices to get it done. Well, I believe it's a pity to hide this feature. Modularity and extensibility often represent a winning point in software, as someone with special needs will always stump in. Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: [EMAIL PROTECTED] ---------------------------------------
