several useful conversations as a result of your feedback. Thank you to
the people who have been participating! We're excited to release this new
API shortly and enable the community to begin to use it.
We've incorporated many of the suggestions you've all provided, and I
wanted to send out an email to discuss why we haven't implemented some
*CC providing the ID for instances and bindings*
This area has been the subject of many complaints, but we've kept it as
originally designed in an effort to balance 2 concerns: making broker
authors implement as few endpoints as possible, and preventing orphaned
services. Several alternatives were proposed, but all of them involved
adding more endpoints or not preventing orphans. We know that some number
of brokers will not be able to use the IDs we provide to identify a
resource, even though they are just GUIDs, and that we are forcing those
brokers to become stateful so they can map our IDs to theirs. Based on my
own experience developing brokers, I suspect that many of these brokers
will eventually have to maintain state as they develop more advanced
feature sets anyway.
For example, to keep our MySQL service broker stateless, we use the
instance GUID as the database name (after removing the dashes). We
likewise use the binding GUID as the username (after removing dashes).
These guids will always be composed of 0-9A-Z and dash, so they should be
usable as broker identifiers in most cases. As we continue to add
features, we eventually will have to keep state on our broker, but have
managed to avoid it so far.
*Gateway Data field*
Allowing brokers to store some data in CCDB seems to solve many problems
for the brokers, but that state would have to be immutable and passed on
every request. I believe that brokers will eventually want to break that
immutability and change their GW data over time, which really means that
they should have been stateful to begin with.
Services should not be aware of individuals, as a space is the owner of a
service instance. If a user is trusted by the space owner to act on a
space, then the service broker should not care who they actually are.
Providing user information encourages broker authors to pay attention to
concepts that don't have meaning in CF.
We appreciate all the feedback we've received from the community and expect
to have a *finalized API in the next week* as part of the public
Director of Engineering, CF Services
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.