Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 23 Jun 2006 15:07:20 +0200
From: Francesco Furfari <francesco.furfari@isti.cnr.it>
Subject: Re: Again on the UPnP and Event Admin service
In-reply-to: <487a994c0606221148x444c5e46m6d0fd6fe2934fc4c@mail.gmail.com>
To: felix-dev@incubator.apache.org
Message-id: <449BE788.5090709@isti.cnr.it>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7bit
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
References: <44980C69.6080601@isti.cnr.it>
 <487a994c0606210550n218a6a4cu54924f200b2beb47@mail.gmail.com>
 <44994711.4040604@isti.cnr.it>
 <487a994c0606210738k307763e9y9fd6a29982b68a7@mail.gmail.com>
 <44995DB8.50104@ungoverned.org> <449967EA.4080103@isti.cnr.it>
 <487a994c0606211335x4ea9ec42k16f15f621d8e1de7@mail.gmail.com>
 <4499DAC0.9040900@isti.cnr.it>
 <487a994c0606220137s3fbd2f40w508560f568f012bc@mail.gmail.com>
 <449A6479.6040007@isti.cnr.it>
 <487a994c0606221148x444c5e46m6d0fd6fe2934fc4c@mail.gmail.com>


Karl Pauls wrote:
> Francesco, Stefano,
>
> I spent the last hours coding the filter stuff. It works now and I
> don't think there is anymore I can do. It needs cleaning-up (that's
> for sure :-) and I will do that when I find some time but otherwise I
> consider it done.
great
>
> Some things to ponder:
>
> First, I was right from the start. Your approach with the 1:1 mapping,
> while nice and easy, is to nice, unfortunately. It will not work.
> Apart from the code duplication (and believe me you would end-up with
> a whole EventAdmin) section 113.7.2 of the spec calls it of. The point
> is that asynchronous events must be delivered in the same order to all
> EventHandlers. I cant see how this can be done with the proposed 1:1
> mapping.
>
 remind me to offer a beer next time you come in Italy ;-)

> Second, I'm changing the filter of the UPnPEventListener on demand and
> it turns out that the
> org.apache.felix.upnp.sample.tv.UPnPEventListener doesn't handle
> ServiceEvent.MODIFIED events. I guess this is a bug and needs to be
> fixed in order for the bridge to work correctly with the example (and
> anywhere else for that matter).
>
ya, the UPnP examples are still far to be considered best UPnP/Osgi 
practice :(
I added the missing code to track service.MODIFIED events.
I tested your code and it works fine.
I  used our examples as well as Intel devices , using both "NULL" filter 
and ServiceId based.
I haven't checked all the possible combinations but looking at your code 
it shouldn't be a problem.

What I've realized is that EA subscriptions are limited respect the 
tracking possibilities offered by the UPnP spec.
Initially I suspected it was a bug in your code, using an handler with 
the following filter:
"UPnP.service.type= urn:schemas-upnp-org:service:SwitchPower:1" the 
light switches were not reported.
But this is consequence of the UPnP events type format in which only the 
deviceId and serviceId are considered.
Hence the EA fails to match handlers with such filters.

So while in the UPnP spec the filters can be any combinations of 
deviceId,deviceType,ServiceId and serviceType,
filters used with EventHandler can be only a combination of deviceId, 
and serviceId.

> Finally, keep in mind that it will still be the case that the
> UPnPEventListener is registered with a null argument as soon as there
> is any EventHandler that doesn't specify an
> EventConstants.EVENT_FILTER. That would be needed regardless of any
> approach. The only thing that can be done about it is to tell people
> that this will lead to unnecessary network load that can be avoided if
> they use a filter that targets the devices/services they are really
> interested in.
>
well this is a user decision, in the old implementation it was an 
imposition ;-)

thanks
francesco
>