Return-Path: Delivered-To: apmail-incubator-river-dev-archive@locus.apache.org Received: (qmail 8122 invoked from network); 11 Jun 2007 21:20:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Jun 2007 21:20:03 -0000 Received: (qmail 39117 invoked by uid 500); 11 Jun 2007 21:20:07 -0000 Delivered-To: apmail-incubator-river-dev-archive@incubator.apache.org Received: (qmail 39015 invoked by uid 500); 11 Jun 2007 21:20:06 -0000 Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: river-dev@incubator.apache.org Delivered-To: mailing list river-dev@incubator.apache.org Received: (qmail 39006 invoked by uid 99); 11 Jun 2007 21:20:06 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Jun 2007 14:20:06 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [192.18.98.34] (HELO brmea-mail-3.sun.com) (192.18.98.34) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Jun 2007 14:20:02 -0700 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5BLJfjq013067 for ; Mon, 11 Jun 2007 21:19:41 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJH00F01PP38L00@mail-amer.sun.com> (original mail from Bob.Scheifler@Sun.COM) for river-dev@incubator.apache.org; Mon, 11 Jun 2007 15:19:41 -0600 (MDT) Received: from [129.148.70.124] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJH00BHNPWNW042@mail-amer.sun.com> for river-dev@incubator.apache.org; Mon, 11 Jun 2007 15:19:36 -0600 (MDT) Date: Mon, 11 Jun 2007 17:19:35 -0400 From: Bob Scheifler Subject: Re: SourceAliveRemoteEvent Part II In-reply-to: <466AF229.7020402@cheiron.org> Sender: Bob.Scheifler@Sun.COM To: river-dev@incubator.apache.org Reply-to: Bob.Scheifler@Sun.COM Message-id: <466DBC67.9000803@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <465C83B4.9020008@dcrdev.demon.co.uk> <465D8E2C.7090503@cheiron.org> <46648B68.6030904@Sun.COM> <4664A018.4010903@cheiron.org> <4665A783.8040004@Sun.COM> <466676B4.30809@cheiron.org> <4666EF37.9090307@Sun.COM> <1181155708.3134.80.camel@cameron> <466714E4.3070501@cheiron.org> <46688C26.2090000@Sun.COM> <46690FDA.2040104@cheiron.org> <4669B201.2030804@Sun.COM> <466AF229.7020402@cheiron.org> User-Agent: Thunderbird 1.5.0.5 (X11/20060731) X-Virus-Checked: Checked by ClamAV on apache.org 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? I also don't understand why SARE event selection is QoS, but other event selections are not. > 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. 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. - Bob