Open Stack

On Mon, Apr 29, 2013 at 7:00 AM, Mark McLoughlin <markmc at redhat.com> wrote:

> On Fri, 2013-04-26 at 15:18 -0400, Doug Hellmann wrote:
>
> > We've gone around a few times with ideas for having better driver-parity
> in
> > the rpc library, so maybe the best thing to do is start by making sure we
> > have all of the requirements lined up. Here's a list of some that I came
> up
> > with based on existing features and my understanding of the shortcomings
> > (numbered for reference, but in no particular order):
>
> Thanks for doing this. We definitely need to be stepping back and
> thinking about this at a high level. I've attempted to step a little
> further back in my writeup:
>
>   https://wiki.openstack.org/wiki/Oslo/Messaging


A few comments/questions on that:

In the client, it seems like the rpc.Target() should be passed to the
RPCClient constructor, rather than specified as a class attribute. The
target parameters should include the host (or "peer" to use Eric's
terminology), shouldn't it?

On the server side, I like separating the dispatcher from the server, but I
wonder if the server needs to know about the dispatcher at all? Why not
just give the server a single callable, which might be a Dispatcher
instance? It isn't clear why the dispatcher has start() and stop() methods,
either, but maybe that has something to do with this design.

In web frameworks the decorator for exposing a method is usually named
something like "expose" so how about rpc.expose instead of rpc.method?

Is fake_rabbit used for testing? If so, that transport should be its own
driver.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130429/06e9f447/attachment.html>