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.
I could say I agree with you, but then we are probably shifting our
difference to what the definition of Quality of Service is/should be.
My definition could be best described as "The set of those quantitative
and qualitative characteristics of a distributed (multimedia) system,
which are necessary in order to achieve the required functionality of an
application." [1]
Based on the above definition I find the constraint for SARE a
reasonable QoS constraint. I'm not saying constraints is without its
problems, for I still miss the ability to inspect which QoS can be
applied or at least to fail early (remember during Davis I asked why
setting constraints through RMC didn't result in an exception if the
proxy knows the constraints can never be satisfied).
As mentioned in the footnote in the response to Dan, if there is a
better mechanism for catering what I would call QoS aspects, both at the
method and proxy level, I'm all ears.
[1] IEEE paper "Distributed Multimedia and Quality of Service: A Survey"
--
Mark
