Hi James, thanks for the idea; What about if I want to black list some images (it might be too big to inline), should I maintain custom headers for that? That's why I decided to use the plug-in cache as opposed to the http cache[1], so I can store non-http data.
This approach also doesn't help on the asynchronous model I've "described"... thanks 1: http://trafficserver.apache.org/docs/trunk/sdk/io-guide/guide-to-cache-api/index.en.html On Tue, Sep 17, 2013 at 8:18 AM, James Peach <[email protected]> wrote: > On Sep 17, 2013, at 6:53 AM, Daniel Morilha <[email protected]> wrote: > > > I am facing similar problem and I ask evaluating TS cache usage. One > clear down side is due its async API, it brings an extra level of > complexity to the final plugin. The plugin fetches, encodes and inline > (possibly multiple) images into the origin's response. Once fetched, I want > to persist the result in memory for the next requests, does it make sense? > > The other approach would be to go with cpp hashmaps knowing I would need > to come with synchronization and eviction mechanisms myself. > > Any considerations? > > The way I'd probably approach this would be to have a helper web service > that does the image encoding for you. Then in the plugin, you can fetch > what you need through the cache and assemble the final response. This lets > you cache everything in ATS with the usual mechanisms. > > > Thanks > > > > On Sep 17, 2013 2:10 AM, "Ethan Lai" <[email protected]> wrote: > > Hi, > > > > I'm going to write a plugin, which needs to store some meta data in > memory. > > Would like to know are there any ways to use InkHashTable data structure > in my implementation? > > > > Thanks, > > -Ethan > > -- Daniel Morilha ([email protected])
