However this is not the best, simplest and straightforward solution to my problem, it seems it may work well.
I've read some of your messages about channels, but haven't got much time to think about it. Do you have your updated source codes available to download, and perhaps some documentation of changes? As I'm working mainly in PHP, I'd consider extending PHP library and compiler to support channels. That could be good step of getting channels to main code. Jan Dolecek [email protected] On Wed, May 26, 2010 at 7:00 PM, James King <[email protected]> wrote: > 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] >> >
