On 12/05/12 06:46 PM, Leif Hedstrom wrote:
Cool. I'm omw to a Mickey Mouse cruise (wish me luck ...), but wanted to
put in a couple of $0.02's.
Welcome back and thanks for this feedback
Should we call it "metalink" or something instead of dedup? Dedup is
something we might want to do later on the cache itself (e.g. deduping
on segments etc.).
Done
If the internal methods works for you, use them by cheating (e.g. copy
paste or steal the header / class definitions). The issue many times is
that our core is C++ whereas the APIs are C, so it's not straightforward
to support them in our public APIs.
I was actually wondering if you advise writing this plugin in C or C++.
I chose C++ only because the core is C++. Maybe it's not important to
decide now, and a good reason to use one or the other will arise later
Can anyone please offer any pointers on writing some functional tests
for this plugin? I would like to maybe automate some tests that, e.g.
* If URL in the "Location: ..." header is cached then this header is
untouched
* If no URL in "Link: <...>; rel=duplicate" header is cached then
"Location: ..." header is untouched
* Test multiple header fields, multiple field values, multiple "Link:
..." parameters, multiple parameter values
But I am new to writing tests that work with Traffic Server. Are there
some recommended tools? Anything consider when planning tests?
Unfortunately I don't have a lot of experience with C/C++ either, so I'm
a little nervous that I am following the Traffic Server code
conventions, or C/C++ best practices in general. I would love any
feedback on the style of this code, before I make *too* many mistakes :-/
e.g. I use one continuation to check if the "Location: ..." URL is
already cached and a different continuation to scan if any "Link: <...>;
rel=duplicate" URL is cached because the behavior of the callback is
slightly different in each case (location_handler() vs. link_handler())
and the only way I could find to define the callback function was to
call TSContCreate() again?
Should local variables be declared at the top of each function, or near
where they are first used?
Any advice on deciding which variables to keep in the Info struct that
is passed from callback to callback, and which to "rematerialize"? e.g.
I pass info->location_loc from callback to callback instead of calling
TSMimeHdrFieldFind() again, but I call TSMimeHdrFieldValueStringGet()
again instead of keeping this string in the Info struct
Thanks for any feedback!
Finally, I gather that ATS creates checksums of content stored in the
cache, and I guess that these checksums are stored in the ATS header for
each HTTP object? Is it possible for a plugin to read these checksums,
for example to build a report of cached URLs with matching checksums, or
add checksums to the HTTP header of cached responses?
