[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Current wildcarding usage (and a strong recommendation to support
target=> in BSC 1.3)
- Subject: Current wildcarding usage (and a strong
recommendation to support target=> in BSC 1.3)
- From: Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>
- Date: Fri, 29 Jul 2005 13:04:05 +0100
--------------000503070107050106070909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Whilst I was re-reading the BSC spec I came across the following line.....
"*However, all devices must respond to the wildcard address
*.*.>*" -
following later discussions on the practicalities of wildcarding this
probably could do with some clarification. This wildcard construct
addresses your main application or device as a whole (ie the main
address without any subaddresses). You should actually also implement
*>* as well. This line was really intended for applications not
supporting full wildcarding. If you do support wildcarding then it
should all work anyway ;-)
Source= <main address>:<subaddress>
Let's use as example a device as follows with one input and two outputs
1) FF123400 ACME.SAMPLE.CONTROLLER
2) FF123401 ACME.SAMPLE.CONTROLLER:SWITCH.OUTPUT
3) FF123402 ACME.SAMPLE.CONTROLLER:SWITCH.INPUT
4) FF123403 ACME.SAMPLE.CONTROLLER:INDICATOR
and a couple of other addresses on your network
5) FF234500 ACME.Heating.SYSTEM.UPSTAIRS
6) FF234600 ACME.Heating.SYSTEM.DOWNSTAIRS
7) FF234601 ACME.Heating.SYSTEM.DOWNSTAIRS:INDICATOR
>:> matches 1,2,3,4,5,6,7 <ie everything>
> matches 1,5,6 (ie all main applications/devices)
>:*.> matches 2,3,4,7 (ie all sub addresses)
The above three are the recommendations for addressing all devices out
there of a particular category .. the next construct was also commonly
used in xAP 1.2 (before sub addressing) and should be supported too. It
is equivalent to >
..
*.*.> matches 1,5,6 (ie all main applications/devices, as in the BSC
spec document )
Some more examples..
*.*.*.* matches 5,6 (this construct means there must be exactly 4
levels present in the main address)
*.*.*.> matches 1,5,6 (this construct means there must be at least 3
levels present but more are ok)
*.>:* matches 4 and 7 only (devices with 1 level of sub address)
>:*.* matches 2 and 3 only (devices with exactly 2 levels of sub
address)
Note the big difference here is the ':' and it's now inclusion in the
wildcard filter. The : provides a limit to how far the wildcard can
match so effectively there are two wildcard constructs , one applying to
the main address and one to the sub address. A * requires a value be
present and a > does not but matches everything following (up to the :
if it is applied before that). Some older applications and libraries do
not apply wilcarding in this way (often they treat . and : as identical)
but practical usage of wildcards has shown that the above usage allows
all combinations of addresses and sub addresses to be wildcarded
correctly and offers the greatest flexibility.
Moving back to the BSC spec therefore you should recognise *.*.> and
also > as addressing your BSC implementation. This is the minimum for
an "address all" address. Actually technically *.> and
*.*.*.> should
also be supported but are rarely used, for completeness please support
it if possible. Note this only addresses the main application and no
sub addresses (endpoints). Also note that if you support wildcards
fully within your application then all of these should work anyway and
don't need specific individual recognition.
Kevin
--------------000503070107050106070909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Whilst I was re-reading the BSC spec I came across the following
line.....<br>
<br>
"<b>However, all devices must respond to the wildcard address
*.*.></b>"
- following later discussions on the practicalities of wildcarding this
probably could do
with some clarification. This wildcard construct addresses your main
application or device as a whole (ie the main address without any
subaddresses). You should actually also implement
<b>></b> as
well. This line was really intended
for applications not supporting
full wildcarding. If you do support wildcarding then it should all work
anyway ;-)<br>
<br>
Source= <main address>:<subaddress><br>
<br>
Let's use as example a device as follows with one input
and two outputs<br>
<br>
1) FF123400
ACME.SAMPLE.CONTROLLER<br>
2) FF123401
ACME.SAMPLE.CONTROLLER:SWITCH.OUTPUT<br>
3) FF123402
ACME.SAMPLE.CONTROLLER:SWITCH.INPUT<br>
4) FF123403
ACME.SAMPLE.CONTROLLER:INDICATOR<br>
<br>
and a couple of other addresses on your network <br>
<br>
5) FF234500
ACME.Heating.SYSTEM.UPSTAIRS
<br>
6) FF234600
ACME.Heating.SYSTEM.DOWNSTAIRS<br>
7) FF234601
ACME.Heating.SYSTEM.DOWNSTAIRS:INDICATOR<br>
<br>
<br>
>:> matches 1,2,3,4,5,6,7
<ie everything><br>
> matches 1,5,6 (ie all main
applications/devices)<br>
>:*.> matches 2,3,4,7 (ie all sub
addresses)<br>
<br>
The above three are the recommendations for addressing all
devices out
there of a particular category .. the next construct was also commonly
used in xAP 1.2 (before sub addressing) and should be supported
too.
It is equivalent to ><br>
..<br>
*.*.> matches 1,5,6 (ie all main
applications/devices, as in the
BSC spec document )<br>
<br>
Some more examples..<br>
<br>
*.*.*.* matches 5,6 (this construct means there must be exactly 4
levels present in the main address)<br>
*.*.*.> matches 1,5,6 (this construct means there must be
at least
3 levels present but more are ok)<br>
*.>:* matches 4 and 7 only
(devices with 1 level of sub address)<br>
>:*.* matches 2 and 3 only (devices with exactly 2 levels of sub
address)<br>
<br>
Note the big difference here is the ':' and it's now
inclusion in
the wildcard filter. The : provides a limit to how far the wildcard can
match so effectively there are two wildcard constructs , one applying
to the main address and one to the sub address. A * requires a
value
be present and a > does not but matches everything following (up to
the : if it is applied before that). Some older applications and
libraries do not apply wilcarding in this way (often they treat . and :
as identical) but practical usage of wildcards has shown that the above
usage allows all combinations of addresses and sub addresses to be
wildcarded correctly and offers the greatest flexibility.<br>
<br>
Moving back to the BSC spec therefore you should
recognise *.*.>
and also > as addressing your BSC
implementation. This is the
minimum for an "address all" address. Actually
technically *.> and
*.*.*.> should also be supported but are rarely used, for
completeness please support it if possible. Note this only
addresses
the main application and no sub addresses (endpoints). Also note
that
if you support wildcards fully within your application then all of
these should work anyway and don't need specific individual
recognition.<br>
<br>
Kevin<br>
<br>
<!-- **begin egp html banner** -->
<br><br>
<div style="width:500px; text-align:right; margin-bottom:1px;
color:#909090;">
<tt>SPONSORED LINKS</tt>
</div>
<table bgcolor=#e0ecee cellspacing="13"
cellpadding="0" width=500px>
<tr valign=top>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads?t=ms&k=Computer+internet&w1=Computer+internet&w2=Developer&c=2&s=38&.sig=5bbJZdfg001HQCSSbY5zIg";>Computer
internet</a></tt>
</td>
<td style="width:25%;">
<tt><a href="http://groups.yahoo.com/gads?t=ms&k=Developer&w1=Computer+internet&w2=Developer&c=2&s=38&.sig=ydixObfEijpILo5U-6NkdQ";>Developer</a></tt>
</td>
</tr>
</table>
<!-- **end egp html banner** -->
<!-- **begin egp html banner** -->
<br>
<div style="text-align:center; color:#909090;
width:500px;">
<hr style="border-bottom:1px; width:500px;
text-align:left;">
<tt>YAHOO! GROUPS LINKS</tt>
</div>
<br>
<ul>
<tt><li type=square> Visit your group "<a
href="http://groups.yahoo.com/group/xAP_developer";>xAP_developer</a>"
on the web.<br> </tt>
<tt><li type=square> To unsubscribe from this group,
send an email to:<br> <a href="mailto:xAP_developer-unsubscribe@xxxxxxx?subject=Unsubscribe";>xAP_developer-unsubscribe@xxxxxxx</a><br> </tt>
<tt><li type=square> Your use of Yahoo! Groups is
subject to the <a href="http://docs.yahoo.com/info/terms/";>Yahoo!
Terms of Service</a>.</tt>
</ul>
<br>
<div style="text-align:center; color:#909090;
width:500px;">
<hr style="border-bottom:1px; width:500px;
text-align:left;">
</div>
</br>
<!-- **end egp html banner** -->
</body>
</html>
--------------000503070107050106070909--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|