Mailing-List: contact dev-help@avro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@avro.apache.org
Message-ID: <4DA88D23.1020508@apache.org>
Date: Fri, 15 Apr 2011 11:23:31 -0700
From: Doug Cutting <cutting@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: dev@avro.apache.org
Subject: Re: Adding a HeaderServer and HeaderTransceiver (Java)
References: <BANLkTikzLZoP9HaMbmFABjFS2n0fbw2b4g@mail.gmail.com>
In-Reply-To: <BANLkTikzLZoP9HaMbmFABjFS2n0fbw2b4g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Have you looked at the RPC Plugin API?

http://avro.apache.org/docs/current/api/java/org/apache/avro/ipc/RPCPlugin.html

You add a plugin to a Requestor or Responder and it can then, among
other things, manipulate request and response metadata.  We might, e.g.,
extend RPCContext to contain the Transceiver so that a plugin
implementation could perform transport-specific actions?  Could
something like this work for your purposes?  For example, one might add
a HeaderRPCPlugin, and HttpTransciever could be made to implement a
Headers interface.

Doug

On 04/14/2011 08:04 PM, Ed Kohlwey wrote:
> Hi,
> I'm working on an application where we want to be able to set
> transport-level headers whenever an Avro RPC is invoked.
> 
> Presently, the Avro Java implementation has no distinction between
> transports that support these types of protocols and normal protocols.
> 
> I'd like to toss around the idea of creating a new abstract server and
> transceiver class. They would include methods that you could use to
> guard method invocations (or return statements) to set headers in the
> transport.
> 
> While this on some level defeats some of a purpose of Avro
> (abstracting the underlying transport), I think it also provides a lot
> of flexibility for a common scenario. There's a number of protocols
> that can be used as transports where headers may be used for multiple
> application level tasks (in the case I have in mind, the header can be
> used for authorization and security labels). It seems very relevant to
> provide a mechanism for setting headers that is consistent across
> protocols.
> 
> Has anyone put any thought into this? Does anyone have feedback on
> this design concept?