Bob Scheifler wrote:
Mark Brouwer wrote:
For me constraints have a similarity with the usage of Configuration to
many of the constructors of the utility classes, it can cater for
aspects that otherwise have to be represented by arguments that might
not be applicable to each and every implementation and to cater for
things not foreseen at design time.
That's what I was afraid was the case. I'm on the opposite side
of the fence, I want constraints to remain in QoS land.
From most perspectives, I consider the ability to receive requested
notifications to be a quality of service issue. So the use of a constraint to
say "please deliver events anyway you can", from my perspective, is an
indication of how I want to constrain the implementation in providing the
service that I have asked for.
The notification problem is a network/transport issue, not an API issue. Its
the endpoint implementation that is the problem, not the API. Adding this sort
of thing to the API, doesn't seem like the right fit for a clean remote
programming model.
Gregg Wonderly
