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 <zwoop@apache.org> 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 <zwoop@apache.org <mailto:
>> zwoop@apache.org>> 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
>
>
|