Return-Path: X-Original-To: apmail-trafficserver-users-archive@www.apache.org Delivered-To: apmail-trafficserver-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1C110E19F for ; Sat, 9 Mar 2013 20:41:20 +0000 (UTC) Received: (qmail 36088 invoked by uid 500); 9 Mar 2013 20:41:19 -0000 Delivered-To: apmail-trafficserver-users-archive@trafficserver.apache.org Received: (qmail 35689 invoked by uid 500); 9 Mar 2013 20:41:19 -0000 Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@trafficserver.apache.org Delivered-To: mailing list users@trafficserver.apache.org Received: (qmail 35681 invoked by uid 99); 9 Mar 2013 20:41:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 09 Mar 2013 20:41:18 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [71.6.165.248] (HELO kramer.ogre.com) (71.6.165.248) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 09 Mar 2013 20:41:12 +0000 Received: from [192.168.201.36] (homey.ogre.com [24.56.188.103]) (authenticated bits=0) by kramer.ogre.com (8.14.5/8.14.5) with ESMTP id r29KelHC021387 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 9 Mar 2013 12:40:48 -0800 Message-ID: <513B9E4F.1030505@apache.org> Date: Sat, 09 Mar 2013 13:40:47 -0700 From: Leif Hedstrom User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Anil J CC: users@trafficserver.apache.org Subject: Re: C++/Java Modules References: <513A9209.4050709@apache.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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 > 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 > > 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