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: pierangelo.masarati@sys-net.it
---------------------------------------
Received on Fri Sep 07 2007 - 23:52:47 MDT
This archive was generated by hypermail pre-2.1.9 : Mon Oct 01 2007 - 12:00:05 MDT