Design for address space bridging #2306
Comments
OverviewThis document describes alternate mechanisms for exposing addresses within one addresspace such that they can be reached DesignAn address space view consists of a restriction over the available addresses within an address space, associating Option a)
Option b)Separate view definition from view exposure
and ...
Option c)Add the view definitions into the address space
while still separating the visibility
|
An alternative d) for consideration (not prefix view with address space, makes it possible to 'reuse' view):
And
|
From an OO model point of view I find b) most appealing. I dislike the fact that information about addresses leaks back into the addressspace in c). I also find Rob's argument that deployment information should be separate persuasive (supporting the separation of |
OK - so I suggest we go with a slightly modified option b) - renaming AddressSpaceViewVisibility to AddressSpaceViewAccess
and ...
Limitationssending to an address will be limited to addresses of type BridgingTo bridge addresses from a remote addressspace to the local address space, an
The address |
I'm ok with the updated proposal, but I'm wondering if we should prefix the views etc. with the address space name or not. Would another approach be to reference these from the address space? Alternatively reference the address space in the spec? Putting a semantic meaning into metadata.name should be avoided if we can IMO. |
@lulf yeah - I wondered about that, I was thinking about putting the address space name in both |
How about:
We can omit the namespace to imply the same namespace as the 'current' resource. We should also consider if we want to set some restrictions that makes the use of namespace relevant or not. I think maybe we shouldn't put that kind of restriction. |
@lulf Looks good to me, other than for
is sufficient I think. And for the bridge, the bridge must be in the same namespace as the addressspace the bridge is being applied to so
|
So, in addition to the proposal above, I think we need to consider how we can bridge to individual addresses which may not be in an address space managed by the same enmasse instance. That is having some way to define a remote network endpoint and associated credentials, and a set of addresses reachable at that endpoint, and the available operations (read/write) on those addresses. Finally I wonder if we should add some sort of mechanism to automatically forward messages from a "local" address/queue to a remote address/queue (or vice versa) |
Overview
A commonly requested feature is the ability to bridge address spaces. I.e. have clients in address space A be able to send/receive from addreesses in Address space B.
Design
TODO
Tasklist
TODO
The text was updated successfully, but these errors were encountered: