On Thu, 05 Jun 2014 08:45:47 GMT, Tavi wrote: 

interface Foo { void foo(); }
class FooImpl { override void foo {} }
	
shared static this {
  auto thriftServerSettings = new VibedThriftServerSettings;
  thriftServerSettings.port = 9090;
  thriftServerSettings.bindAddresses = ["::1", "127.0.0.1"];
 
  // use default TBinaryProtocol, TBufferedTransport
  alias FooService = VibedThriftService!(Foo, FooImpl); // use default TBinaryProtocol, TBufferedTransport
 
  listenThrift!FooService(thriftServerSettings);
}

For each connection a new FooImpl processor object will be created. Maybe using a free list (or typed custom allocator) would be better.

I'm not sure if I agree with your rationale for creating one service instance per connection. In the Thrift universe, a service is semantically something stateful which clients can invoke methods on via a stateless connection. In this regard, Thrift is actually very similar to a REST architecture. For example, the instance implementing Foo would typically access some database or your in-process domain model.

Thus, there needs to be some way for whatever processes the client request to access that state. In the vanilla Thrift library (in the C++, Java and, by extension, also D implementation), this is achieved by having one instance of the service interface implementation per server.

Now, of course, in some cases, keeping the connections entirely stateless is just not enough. You mentioned one of them, authentication. One way, of course, would be to push all authentication concerns down to the transport layer. This precludes for example simply using RPC calls for "logging in", though (and let us ignore the question on whether this is a good pattern in the first place for now). For this reason the vanilla Thrift implementation, if conceptually geared towards a stateless model, offers an opportunity to attach contextual information to a connection, either by writing a custom TProcessorFactory to create a processor instance per connection, or by using a TProcessorEventHandler. You could write a custom

I'm almost certain that it is possible to find a more natural, less "Java-ish" design for this in the context of the Vibe.d I/O model. However, it will need to address the question of how to share state somehow.

David