Re: Modules, installing Squid headers, and src layout

From: Alex Rousskov <rousskov@dont-contact.us>
Date: Fri, 12 Oct 2007 09:35:26 -0600

On Fri, 2007-10-12 at 16:20 +0200, Henrik Nordstrom wrote:
> I prefer not supporting loadable modules except where
> there is very well defined boundaries.

My current focus is on eCAP, where the boundary is being defined at
http://wiki.squid-cache.org/Features/eCAP

As for other possible module uses, let's discuss them when somebody
actually starts working on them.

I have to note for the record that virtually any well-defined boundary
can be ignored or abused by a module, but that is not a problem we can
solve or should be seriously concerned with, IMO.

> Only headers which have been cleaned up to a level of providing a stable
> interface should be exported for use by external modules.

I would like that, but I am not sure this ideal approach is practical
today.

Personally, I am comfortable exporting dirty stuff as long as we do not
make any promises that it will remain stable. If somebody decides to
rely on unstable interfaces it would be _their_ responsibility to keep
their modules in sync. If they do not want that, nobody is forcing them
to write a module.

Said that, I will try to cleanup as much exported stuff as I can.

For eCAP, we need to export message headers and bodies to start with,
which is already a big chunk if you think about dependencies. The next
step would be to export network I/O, asynchronous calls, and host name
resolution. I know a few modules that would need that.

Again, I would try to polish things and minimize exposure. I will try to
wrap dirty things in simple/polished interfaces where cleanup would be
prohibitively expensive.

> The headers that are candidates for this should be cleaned
> up to a level that they provide a stable interface, and moved to
> include/squid/

Are you sure src/include/squid/ is better than src/squid/? In my
experience, src/squid/ is better because it lets you keep related things
together.

This is especially true when you consider sub-directories. It is awkward
to work with, say, ICAP sources that are spread across

        src/include/squid/ICAP/
and
        src/ICAP/

IMO, keeping everything in src/squid/ICAP/ simplifies developers life a
lot. Is there a particular reason you prefer the src/include/squid/
option?

Thank you,

Alex.
Received on Fri Oct 12 2007 - 09:35:36 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Oct 30 2007 - 13:00:03 MDT