I think Bryan already did - https://github.com/apache/trafficserver/tree/master/plugins/experimental/hipes
On Sat, Mar 9, 2013 at 12:40 PM, Leif Hedstrom <[email protected]> wrote: > On 3/8/13 9:08 PM, Anil J wrote: > >> Just realized that earlier reply just addressed to Leif. Addressing it to >> mailing list. >> >> On Fri, Mar 8, 2013 at 8:36 PM, Leif Hedstrom <[email protected] <mailto: >> [email protected]>> wrote: >> >> On 3/8/13 6:28 PM, Brian Geffon wrote: >> >> I do not think this is a good idea, if you're really looking to >> write code in Java I would suggest maybe using Netty and writing a >> simple proxy that way as opposed to using trafficserver. >> Alternatively, you could take advantage of remapping to just >> rewrite the url to a special endpoint that will fetch the original >> content and return a modified response to trafficserver. >> >> >> >> This is what people use the ICAP protocol for: >> >> http://www.ietf.org/rfc/**rfc3507.txt<http://www.ietf.org/rfc/rfc3507.txt> >> >> Are you suggesting to use ICAP interface instead of libCurl/HTTP, in the >> module? Or the having a module in the HTTP path, which goes outside for >> processing itself is not good idea? I still not clear about Brian's opinion >> why not to use trafficserver. >> > > I'm saying, if you are going down the route of having "external" helper > applications to do content adaption, you should consider the ICAP protocol. > > > >> In my use case, I just want to leverage the third party application >> servers (e.g. transcoders) to adjust the media content to suite the end >> user client's requirement. >> > > Nod, that's exactly what ICAP does. Now, if you third party applications > talks HTTP, you can just do what was suggested, and proxy requests through > them. I did a little thing for Yahoo a while back, called HIPES, which made > it easy to "pipeline" such application servers. Bryan, can you open source > HIPES? :) > > -- Leif > >
