Mike: Thanks for explaining how your brokers would need modifications for
sharing to work as desired. I'll investigate how we can allow brokers to
explicitly opt in to sharing (either via the requires field or some other
mechanism). I'll also look into a workflow where a space developer who has
an instance shared into their space can trigger an I share/remove. Thanks
for the great feedback!

Thanks Matt. It also helps to know that bind will include space and org
guid. Any thoughts on my other comments? For your convenience I've pasted
them below.

Mike


Thanks for the feedback Mike, and great questions! We're currently working

off slightly different assumptions, but are working through these to
validate that they are the expected behaviour for the majority of users:

* Space developers in the 'owning' space (this is the way we've thought
about this too!) *would *be able to delete or unshare a shared service
instance with bindings, but they would get a warning in the CLI warning
them that this will automatically delete bindings in other spaces.

Interesting. That behavior is different for bindings in the owning space.
Today if a space developer wishes to delete a service in its owning space,
that is bound to applications, the operation will fail until that service
is unbound. I wonder if the CAPI or CLI team would consider changing that
behavior so that the functionality is equivalent between shared and not
shared services?

If the space developer in the owning space attempts to delete a service and
the unbind fails in a shared space then I assume the delete service request
will also fail correct?

* Space developers can only bind and unbind to service instances that have

been shared into their space. In this first version they wouldn't be able
to remove the service instance from appearing in their space without asking
the sharer to unshare it.

If the org manager of an org who has a space with a shared service in it
wishes to delete the space a service is shared in, then I assume that would
succeed without the owning space developer first unsharing the service
correct? If so it seems kind of strange they can unshare the service by
deleting the space but not by simply unsharing it individually. Why not
let the space developer of a space a service is shared into let that space
developer unshare the service? Is there some hidden complexity I'm missing?