river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: SourceAliveRemoteEvent Part II
Date Mon, 11 Jun 2007 22:24:29 GMT
Bob Scheifler wrote:
> Mark Brouwer wrote:
>> 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 don't get how asking for SARE events translates into a quantitative
> or qualitative characteristic, could you explain?

To me it is a qualitative characteristic of an application that it
capable of giving me a sign of its existence every x seconds.

I value a lookup service that is capable of letting me know every 30
seconds e.g. it is still thinking of me and capable to deliver an event
higher than one that leaves me in the dark whether it is still there and
capable of reaching me. Assuming 2 lookup services are equal for all
aspects besides their ability to support SARE I would go for the one
supporting SARE.

> I also don't understand why SARE event selection is QoS, but other
 > event selections are not.

SARE is something that you get or don't get as part of an event
registration so it is an additional feature, it is not an independent
event registration.

SARE is not a 'business protocol', they are just additional events that
come over the same event stream as the business events for which you

>> 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.
> If SARE is an example, then method arguments seem a better mechanism.

If SARE would be specified as part of the event protocol of a service I
agree as it would mean each service has to support it. It is optional as
I envisioned it I don't want to have it as an argument.

Do you believe that method arguments for something that is optional is
fine. Some implementations might delay remote events for whatever
reason, should we put an extra parameter in the business interface? How
many method arguments are we going to add, that might make no sense to
some implementations. Must all implementors what till the next revision
of the spec to support something, must all developers change the method
calls in their application to make use of it.

> The way I think of QoS, it additionally seems peculiar to be putting
> QoS constraints on the event registration to affect event delivery;
> QoS on event delivery should be done by placing constraints on the
> event listener.

I don't see the problem. The QoS constrains works over the complete
event registration, and not for the individual event delivery. As such I
find the event registration a better place. The event registration is
the moment where you tell the server: "I want to receive certain events
for the following duration, oh and if possible (constraint as
preference) I want you to notify me every 30 seconds with an event even
when no 'business event' takes place (that when you get the SARE).".

What is wrong in this human language that makes saying "oh and if
possible I want you to notify me every 30 seconds with an event even
when no 'business event' takes place" so strange that it can't be part
of the event registration.

Also it is the client who wants to apply the QoS constraints that the
server has to find out about, I don't see how setting a constraint on
the event listener can make that happen.

I think we've had a similar discussion with JavaSpace05.contents about
whether constraints can be specified at an method at which they don't
seem to operate (which IMHO is not the case with SARE) and JavaSpace05
has language that makes it clear that constraints for the contents
method work for the next method of the MatchSet.

View raw message