From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8763 invoked by alias); 2 Sep 2010 04:11:08 -0000 Received: (qmail 8752 invoked by uid 22791); 2 Sep 2010 04:11:07 -0000 X-SWARE-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from relay.ihostexchange.net (HELO relay.ihostexchange.net) (66.46.182.57) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 02 Sep 2010 04:11:01 +0000 Received: from mailhost.internal (203.206.165.193) by smtp.ihostexchange.net (66.46.182.50) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 2 Sep 2010 00:10:55 -0400 Received: from [172.29.254.198] (unknown [172.29.254.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.internal (Postfix) with ESMTPSA id 2155D3078F; Thu, 2 Sep 2010 14:09:33 +1000 (EST) Message-ID: <4C7F23CA.1080202@evostor.com> Date: Thu, 02 Sep 2010 04:11:00 -0000 From: Greg Banks User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "nathans@aconex.com" CC: "Frank Ch. Eigler" , "pcp@oss.sgi.com" , "systemtap@sources.redhat.com" , Mark Goodwin Subject: Re: [pcp] suitability of PCP for event tracing References: <1219414988.590221283398911155.JavaMail.root@mail-au.aconex.com> In-Reply-To: <1219414988.590221283398911155.JavaMail.root@mail-au.aconex.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q3/txt/msg00350.txt.bz2 nathans@aconex.com wrote: > ----- "Greg Banks" wrote: > > >> >> [...] create a very >> simple stateless HTTP-to-PCP protocol bridge daemon [...] >> > > That echo's my thoughts, we should be able to extend pmproxy to do this > too - instead of simply proxying native protocol, it could convert from > XML/JSON client requests on the front end to regular PCP protocol on the > backend (optionally, and only if the client requests come in that way so > existing proxy protocol unchanged). Then we wouldn't need a new daemon, > etc. > > Sure we could do it in pmproxy, but I don't see what it buys us other than not having to start one more daemon in the init script? -- Greg.