> 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
