Unfortunately I cannot give you an answer that you can use today, however
perhaps in the future when I am able to release my code back to the project...
Using the Channel notion would probably be appropriate here. I posted about it
as a new concept on the dev thread a couple weeks back. You would assign each
functional area a channel, or each device type a channel depending on how you
want it to work. Each channel hosts a single Thrift service. You can have up
to 256 channels per listening endpoint.
I have this coded, debugged in C# for Thrift. Implementing the same TEndpoint
code in other languages should be straightforward following the code as a
guide. I will see if I can rush along the legal approval needed to get this
contributed from within.
So for example if you have four Thrift services each in their own file:
diags.thrift: service Diags { void BeginDiagnostics(); ... }
blocking.thrift : service Blocking { ... }
info.thrift : service Info { ... }
snmp.thrift : service SNMP { ... }
channels.thrift : struct Default { Diags = 1, Blocking = 2, Info = 3, SNMP = 4 }
You would then implement the abstract class TListeningEndpoint on the server
side like this:
TSecureServerSocket tServerSocket = new TSecureServerSocket(port,
cert);
m_server = new TListeningEndpoint(tServerSocket,
maxConnectedClients);
m_server.ClientConnected += m_server_ClientConnect;
m_server.Start();
When a client connects, it gets initialized by the delegate:
void m_server_ClientConnect(TConnectedEndpoint client)
{
client.AddRequestProcessor(Channels.Default.Diags, new
Diags.Processor(new MyDiagsImpl()));
client.AddRequestProcessor(Channels.Default.Blocking, new
Blocking.Processor(new My Blocking Impl()));
client.AddRequestProcessor(Channels.Default.Info, new
Info.Processor(new MyInfoImpl()));
client.AddRequestProcessor(Channels.Default.SNMP, new
SNMP.Processor(new MySNMPImpl()));
client.SetConcurrentInboundRequestLimit(m_maxConcurrentRequestsPerCall);
client.Disconnected += new
TConnectionDelegate(connectedClient_Disconnected);
}
On the client side, you would connect with a TConnectedEndpoint and then use
the clients like this:
Diags.Client diagClient = new Diags.Client(myEndpoint,
Channels.Default.Diags);
diagClient.BeginDiagnostics();
So anyway this is not part of Thrift yet, but I'm hoping to get the initial
implementation in C# pushed into the project soon. This would allow you to
make different implementations of the same service on different channels, which
I believe is what you are looking for.
James E. King, III
Dell (EqualLogic) HIT Team (ASM)
-----Original Message-----
From: Jan Dolecek [mailto:[email protected]]
Sent: Wednesday, May 26, 2010 10:24 AM
To: [email protected]
Subject: Re: multiple inharitance of services
Or it could be something like include, but inside of a service definition.
Now I'm implementing some services which would be great to split into several
small files and then include them into one big service provided by one handler.
Now I gotta Copy&Paste the definitions, which is very unflexible.
My problem is communication with network devices, access points and some
servers, so I've prepared services:
- Diagnostics (functions ping, arping, traceroute....)
- Blocking (blockIP, unblockIP.....)
- Device info (getSysName, getIPAddressList,.....)
- SNMP (activateSNMP, deactivateSNMP, setCommunity)
- .... several others
Now, when looking at concrete devices:
- first one supports diagnostics, blocking, device info, but not SNMP.
I was thinking about devining service myDevice1 with apropriate sub-services.
- another one supports just device info
- third supports all but blocking...
My ideas are:
1/ service, which could extend more services in thrift file. No name collisions
are allowed. When generating classes for concrete languages, thrift could do
the copy&paste of all required methods.
Therefore, language not needs multiple inharitance.
2/ include for services - in thrift file, i'll use sth. like include inside of
service definition. No inharitance will be done. Thrift will just copy all
functions from included service and paste them into the including one.
What do you think about this? Or do you have some other solution to my problem?
Thanks for info
Jan Dolecek
[email protected]
On Fri, May 21, 2010 at 2:53 AM, Mark Slee <[email protected]> wrote:
> Sorry for the super-slow response, not sure if this ever got replied to.
>
> This was never implemented to avoid the implementation complexity it would
> introduce into languages that don't support multiple inheritance, and because
> there were decent alternate solutions for most of the problems it would
> solve. It is true that Thrift services are just interfaces. However, we do
> end up generating some base classes for services (such as the method dispatch
> handlers, etc.) With single-inheritance, it is quite straightforward to
> compose services in a single-inheritance chain, and there are clear semantics
> for what to do with method-name collisions (child class goes first, fall back
> to parent class).
>
> It would definitely be possible to get multiple service inheritance working,
> but the implementation would likely require some code duplication or tricky
> object compositions in languages that don't support multiple inheritance or
> things like mixins. It could all be done, it's just a question of trading off
> complexity/maintenance/testing/etc. vs. the added utility of the feature.
>
> I think the feature that most people actually want here is not multiple
> inheritance, but rather the ability to run multiple Thrift services into one
> TServer engine. I think it's rare that people actually want to compose the
> service implementations into a single multiply-inherited class. Rather, they
> just don't want to have to run 3 services on 3 different ports.
>
> The big issue to navigate there is just the method dispatching -- how do you
> decide which method maps to which service, and what do you do if two services
> have a collision on a method name. If a simple rule was put in place that
> multiply-embedded services may not have ANY method name collisions, doing
> that would be quite straightforward (just have each service export a map of
> string => method callback, and then merge the map for all services). To
> support method-name collisions would likely require introducing something
> like a service identifier into the protocol.
>
> Cheers,
> mcslee
>
> -----Original Message-----
> From: Jan Dolecek [mailto:[email protected]]
> Sent: Tuesday, May 11, 2010 8:39 AM
> To: thrift-dev
> Subject: Q: multiple inharitance of services
>
> I wonder, why Thrift _not_ supports multiple inharitance of services.
>
> I mean, services as defined by thrift are just interfaces and it's
> common practice in many programming languages, that class can
> implement more than one interface. Why is this not possible with
> thrift?
>
> Thanks for info
>
>
> Jan Dolecek
> [email protected]
>
