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.

Thus, my 'rather leave it for StringNg' in 3.2. ;)

>
>>> 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.

Aye.

Amos
Received on Mon Mar 09 2009 - 21:36:03 MDT