Hi Doug, Thanks for the tip. I think this can probably work. I take it that requestCallMeta() basically returns a map of the headers and their values? Are there any gotchas here in terms of supporting UTF-8 encodings in the byte buffer or anything like that?
On Fri, Apr 15, 2011 at 2:23 PM, Doug Cutting <[email protected]> wrote: > 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? >
