Re: [MERGE] SourceLayout: acl/, take1

On 03/09/2009 12:49 AM, Amos Jeffries wrote:
>> urlCanonical is currently an always-asserting stub. I am not sure
>> what pulls in urlCanonical. I know storeKeyPublicByRequest* require
>> it, but I am not sure which source requires storeKeyPublicByRequest.
>> If the stub assertion fails on some cache files, we will need to pull
>> more sources or re-implement urlCanonical.
>
> URL stuff is about to become a stand-alone class dependent only on
> StringNg and provide all URL/URI manipulation and storage.
> I would rather wait for StringNg, but some of it can be pushed forward
> and use old-String if it has to.
The problem here is that current urlCanonical takes HttpRequest as a
parameter. Thus, any working stub or full implementation would have to
pull in Http* classes, which would pull in half of Squid.

I agree that it would be nice to have a stand-alone Url class, but it
would take time to untangle url* code from higher-level protocols. We
are, essentially, paying the price for years of architectural neglect
when code was added into "one big pile", without respect for layers and
boundaries. As we are migrating towards libraries, the linker catches
some of these architectural violations due to circular dependencies.

>> The more sources are moved into libraries, the more difficult it may
>> be to write isolated, compact test cases or tools because test case
>> stubs and customizations may start to conflict with names defined in
>> the libraries and because pulling in a whole library might require
>> defining more stubs. It is not clear yet how real this concern is in
>> general, but a lot of acl/ SourceLayout time was spent on making
>> ufsdump build...
>
> The stub model still applies, just the unit focus changes from
> linked-files to linked-libraries.
>
> Each library should have a stub alternative for its whole API.
> So we link to the libraries we need, and stub all the libraries we
> don't need to link.
>
> It's only a real concern for unit-tests at present, thus the above
> design will work happily.

While it is possible to provide library stubs, I am not sure we have the
resources to focus on that. Some test cases may have to be disabled as
more stuff is moved and put into libraries. Let's debate that when we
actually have a test case that cannot be adjusted without library stubs
though.

Thank you,

Alex.
Received on Mon Mar 09 2009 - 14:25:36 MDT