[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: xAP EOM identifier in xAP v1.3
--0014852e19407cb15a04737aac27
Content-Type: text/plain; charset=ISO-8859-1
I will dig it out - it included an optional checksum I think, and IIRC was
framed by stx and etx (a kind of pseudo industry standard). I certainly
used
it with the PIC serial stuff and the xAP-serial bridge.
Re.: long message truncation and concatenation: If we need to support
messages that are larger than one UDP packet, then there are additional
complexities and the proposed scheme won't work as intended as the ordering
of UDP messages is not guaranteed. I'm happy to help refine a spec to
support these capabilities, but it is moving away from the basic ethos of
xAP somewhat, as devices would have to be able to buffer received messages,
and that raises the bar considerably. Perhaps there is scope for
co-existence of a long and standard message protocol though?
Patrick
2009/9/13 Kevin Hawkins <yahoogroupskh@xxxxxxx>
> ... Oh ... where is that in the spec ? it might be all we need.
>
> This is also tied in with some aspects of long message truncation
> and concatenation of messages received in UDP receive buffers
though...
>
> K
>
> Patrick Lidstone wrote:
> >
> >
> > The original xap spec provides extensions for framing a message
over
> > async serial which also delimit the start of the message - you
don't
> > need this 'hack' if you follow the original spec for non-UDP
transports.
> >
> > Patrick
> >
> > 2009/9/13 Kevin Hawkins <yahoogroupskh@xxxxxxx
> > <mailto:yahoogroupskh@xxxxxxx>>
> >
> > We have been asked on several occasions how to detect the
end of a
> > xAP messager as there is no unique EOM character. Typically
in any
> > reasonable sized packet structured transport eg UDP then the
packet
> > provides such an indication but on systems with small packets
or
> > non eg
> > asynchronous serial this is not useable.
> >
> > In discussing this with the specification team we must
consider
> > backwards compatability and so we do not wish to alter the
> > specification
> > to include a unique EOM character. What we do propose
however is
> that
> > xAP v1.3 will specify that all messages should end with two
> > consecutive
> > chr(10)'s immediately after the closing '}'
> >
> > ie ..... 7D 0A 0A
> >
> > Some apps, even v1.2 ones, already do this. We don't
believe this
> > will cause any backwards compatibility issues and it will
always be
> > unique within a xAP message.
> >
> > So, in developing xAP v1.3 apps could you therefore append
two 0A's
> > at the end of your messages , and of course handle incoming
messages
> > containing such.
> >
> > K
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> > mailto:xAP_developer-fullfeatured@xxxxxxx
> > <mailto:xAP_developer-fullfeatured@xxxxxxx>
> >
> >
> >
> >
> >
> >
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
--0014852e19407cb15a04737aac27
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<head>
<style type=3D"text/css">
<!--
/* start of attachment style */
.ygrp-photo-title{
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
}
div.ygrp-photo{
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
}
div.photo-title=20
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;=20
}
div.attach-table div.attach-row {
clear: both;
}
div.attach-table div.attach-row div {
float: left;
/* margin: 2px;*/
}
p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
}
div.ygrp-file {
width: 30px;
valign: middle;
}
div.attach-table div.attach-row div div a {
text-decoration: none;
}
div.attach-table div.attach-row div div span {
font-weight: normal;
}
div.ygrp-file-title {
font-weight: bold;
}
/* end of attachment style */
-->
</style>
</head>
<html><head>
<style type=3D"text/css">
<!--
#ygrp-mkp{
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 14px 0px;
padding: 0px 14px;
}
#ygrp-mkp hr{
border: 1px solid #d8d8d8;
}
#ygrp-mkp #hd{
color: #628c2a;
font-size: 85%;
font-weight: bold;
line-height: 122%;
margin: 10px 0px;
}
#ygrp-mkp #ads{
margin-bottom: 10px;
}
#ygrp-mkp .ad{
padding: 0 0;
}
#ygrp-mkp .ad a{
color: #0000ff;
text-decoration: none;
}
-->
</style>
</head>
<body>
<!-- **begin egp html banner** -->
<br><br>
<!-- **end egp html banner** -->
I will dig it out - it included an optional checksum I think, and IIRC was
=
framed by stx and etx (a kind of pseudo industry standard). I certainly
use=
d it with the PIC serial stuff and the xAP-serial bridge.<br>Re.:
long mess=
age truncation and concatenation: If we need to support messages that are
l=
arger than one UDP packet, then there are additional complexities and the
p=
roposed scheme won't work as intended as the ordering of UDP
messages i=
s not guaranteed. I'm happy to help refine a spec to support these
capa=
bilities, but it is moving away from the basic ethos of xAP somewhat, as
de=
vices would have to be able to buffer received messages, and that raises
th=
e bar considerably. Perhaps there is scope for co-existence of a long and
s=
tandard message protocol though?<br>
<br>Patrick<br><br><div
class=3D"gmail_quote">2009/9/13 Kevin Hawkins <span=
dir=3D"ltr"><<a href=3D"mailto:yahoogroupskh@xxxxxxx";>yahoogroup=
skh@xxxxxxx</a>></span><br><blockquote
class=3D"gmail_quote" styl=
e=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt
0.8ex; =
padding-left: 1ex;">
... Oh ... where is that in the spec ? =A0it might be all we
need.<br>
<br>
=A0 =A0This is also tied in with some aspects of long message
truncation<b=
r>
and concatenation of messages received in UDP receive buffers
though...<br>
<br>
=A0K<br>
<div class=3D"im"><br>
Patrick Lidstone wrote:<br>
><br>
><br>
> The original xap spec provides extensions for framing a message
over<b=
r>
> async serial which also delimit the start of the message - you
don'=
;t<br>
> need this 'hack' if you follow the original spec
for non-UDP t=
ransports.<br>
><br>
> Patrick<br>
><br>
> 2009/9/13 Kevin Hawkins <<a href=3D"mailto:yahoogroupskh@googlemail=
.com">yahoogroupskh@xxxxxxx</a><br>
</div>> <mailto:<a href=3D"mailto:yahoogroupskh@xxxxxxx";>yahoo=
groupskh@xxxxxxx</a>>><br>
<div class=3D"im">><br>
> =A0 =A0 =A0 We have been asked on several occasions how to detect
the =
end of a<br>
> =A0 =A0 xAP messager as there is no unique EOM character.
=A0Typically=
in any<br>
> =A0 =A0 reasonable sized packet structured transport eg UDP then
the p=
acket<br>
> =A0 =A0 provides such an indication but on systems with small
packets =
or<br>
> =A0 =A0 non eg<br>
> =A0 =A0 asynchronous serial this is not useable.<br>
><br>
> =A0 =A0 =A0 In discussing this with the specification team we must
con=
sider<br>
> =A0 =A0 backwards compatability and so we do not wish to alter
the<br>
> =A0 =A0 specification<br>
> =A0 =A0 to include a unique EOM character. =A0What we do propose
howev=
er is that<br>
> =A0 =A0 xAP v1.3 will specify that all messages should end with
two<br=
>
> =A0 =A0 consecutive<br>
> =A0 =A0 chr(10)'s immediately after the closing
'}'<br>
><br>
> =A0 =A0 ie =A0..... 7D 0A 0A<br>
><br>
> =A0 =A0 =A0Some apps, even v1.2 ones, =A0already do this. =A0We
don=
9;t believe this<br>
> =A0 =A0 will cause any backwards compatibility issues and it will
alwa=
ys be<br>
> =A0 =A0 unique within a xAP message.<br>
><br>
> =A0 =A0 =A0So, in developing xAP v1.3 apps could you therefore
append =
=A0two 0A's<br>
> =A0 =A0 at the end of your messages , and of course handle
incoming me=
ssages<br>
> =A0 =A0 containing such.<br>
><br>
> =A0 =A0 =A0 K<br>
><br>
><br>
> =A0 =A0 ------------------------------------<br>
><br>
> =A0 =A0 Yahoo! Groups Links<br>
><br>
><br>
</div><div><div></div><div
class=3D"h5">> =A0 =A0 =A0 =A0mailto:<a href=
=3D"mailto:xAP_developer-fullfeatured@xxxxxxx";>xAP_developer-fullfe=
atured@xxxxxxx</a><br>
> =A0 =A0 <mailto:<a href=3D"mailto:xAP_developer-fullfeatured@yahoog=
roups.com">xAP_developer-fullfeatured@xxxxxxx</a>><br>
><br>
><br>
><br>
><br>
><br>
><br>
<br>
<br>
<br>
------------------------------------<br>
<br>
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|