Adding a context parameter is possible, but I'm not in love with the idea. We would have to either (a) include a dummy value in client requests or (b) create different client and server interfaces, making it more difficult to call handlers directly.
The way that I've thought of doing this before was replacing the handler with a "handler factory" that could either return a fixed pointer to the handler (equivalent to the current system) or allocate a handler per request. Then, the server would call methods on the handler before invoking the main method, allowing it to do application- specific processing of metadata. --David Bryan Duxbury wrote: > It's true that you can't do this today. It'd be a nice feature to > have, though, for sure. Anyone have a good idea of how we should go > about implementing this? Last parameter is always the context? > > -Bryan > > On Dec 15, 2008, at 5:05 PM, Luke Lu wrote: > >> I wanted to implement logging (and later ACL) for a thrift broker/ >> server. But I'm having trouble getting connection info (remote ip >> address etc.) from server handlers. In other rpc alternatives, you >> get this from a connection context passed in as an argument (e.g., >> Ice's Ice::Current). >> >> I remember someone submitted a patch but I can't seem to find a >> JIRA ticket/patch for this. How else do people implement API >> specific logging and access control? Help? >> >> __Luke >> >> P.S. Apology if this is a resend (I got no ack from the list >> server, but no post/response either.) >
