Thank you Kenton & Shane - it must have been a slow brain day for me
yesterday :-)

I confused the underlying implementation with what PB provides. The
RPC system doesn't know or care how data is transferred.

On Nov 20, 5:56 pm, Shane Green <[EMAIL PROTECTED]> wrote:
> It sounds like the system in question has a single "public" service with
> delegates calls to back-end services, distributed across machines
> available to it.  It seems as though the public service provides an
> interface which is essentially a composition of the interfaces provided
> by the services available to it.  

That's is exactly.

> The process of accepting requests for methods it provides on behalf of
> these back-end services, which it handles by delegating to the
> appropriate back-end service, is essentially multiplexing multiple
> services from a single network location.
>
> If this is at all accurate, then I believe that the API exported by the
> public service should be built, dynamically, based on the set of
> interfaces available to it.  Taking this approach would allow each
> service to define its own interface.  While all the functionality
> available on the network can be exposed as though it were all provided
> by a single entity, assuming there are no naming conflicts ;-)

That sounds like what I should be doing. I was just making it hard for
myself by thinking it was more complicated than it is.

> Or maybe I'm completely confused about the setup.

No, I think you've got it right.

Thanks,
Jeff
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to