[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Re: Moving to TSC?
--0016e6d77f748851a50484f9d571
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Kevin & Daniel
Back in 2007 when the TSC spec first came out I started work on an app
called PIDSim. This was a hack of a pre-existing app with the addition of
BSC, TSC and xAPTSC message creation, the intention being to add it to my
xAPLabs series as an aid to testing.
I posted a picture here http://www.netcompsys.co.uk/pidsim.jpg
. I got as
far as creating the messages for changes in the analog components and a few
people even had a play with the app itself.
I do remember recieving a couple of what I considered to be sharp and
unhelpful remarks at the time and since there seemed to be no great
interes=
t
then, I abandoned it an moved on to other things.
However the app still works and still generartes the messages, and if it is
of any help to you please contact me off list
Kevin T
On 29 March 2010 13:29, Daniel Berenguer <dberenguer@xxxxxxx> wrote:
>
>
> This is something that we can't postpone IMO. Although I had expected
a
> higher interest on this subject, I agree with Lehane in that someone
shou=
ld
> take the first step and try to implement TSC into a controller. This
woul=
d
> give us a better idea about the strengths and weakness of TSC in
embedded
> devices and maybe will inspire other developers as well.
>
> In a few weeks, Kevin H and me are going to work on a TSC
implementation
> for opn-mbs. This will give us the opportunity to take a more
practical
> glance at the issue. We'll come back then with new questions so we'll
be
> able to start a debate in a proper way.
>
> Daniel.
>
>
> --- In xAP_developer@xxxxxxx <xAP_developer%40yahoogroups.com>,
> "Daniel Berenguer" <dberenguer@...> wrote:
> >
> > I support Lehane's proposal about re-working TSC. I think that,
with so=
me
> minor changes, TSC could become pretty usable, even for embedded
devices
> with current BSC support.
> >
> > Daniel.
> >
> >
> > --- In xAP_developer@xxxxxxx
<xAP_developer%40yahoogroups.com>,
> "Lehane Kellett (g8kmh)" <g8kmh@> wrote:
> > >
> > > Kevin,
> > > I think xAPBSC and TSC can only co-exist in some simpler
devices - my
> > > current (only) implementation is for the TOM10 where (a) the
code is =
C#
>
> > > .NET and so space isn't an issue and (b) the xAPBSC
implementation
> > > hasn't changed from a previous version. Where the complexity
of TSC i=
s
> > > required then xAPBSC may be a subset, typically I'd expect
for
> > > status/reporting purposes rather than control, although
gross control
> > > (on/off) could be either.
> > >
> > > Given the status of TSC and the low number of adopters maybe
we shoul=
d
> > > look at some revisions or even deprecation of some elements
in order =
to
>
> > > help adoption?
> > >
> > > Lehane
> > >
> > >
> > >
> > > Kevin Hawkins wrote:
> > > >
> > > >
> > > > I had always envisaged BSC and TSC both existing side
by side and
> > > > hopefully being supported by nearly all devices. My
hope with TSC w=
as
> > > > that it would be sufficiently similar to BSC that it
could share
> large
> > > > areas of code and not really incur any extra overhead
in supporting
> both
> > > > rather than just say TSC. In a way TSC being BSC with
extra
> parameters
> > > > and a relaxation of some constraints on existing ones
(eg decimal
> > > > places, negative values etc). Obviously by it's nature
TSC will be
> > > > more involved than BSC.
> > > >
> > > > At this stage I'm feeling we haven't quite achieved
that but maybe
> > > > others don't agree with an intention ever to try and do
so ? Having
> > > > played a little with TSC it doesn't present that
commonality - mayb=
e
> > > > that's the nature of the beast - but I have a few
reservations abou=
t
> the
> > > > schema and had great difficulty in creating a sensible
model to
> > > > implement it alongside BSC. Lehane - have you actually
got both BSC
> > > > and TSC fully implemented in your embedded devices ?
> > > >
> > > > K
> > > >
> > > > On 22/03/2010 17:29, Daniel Berenguer wrote:
> > > > > Thanks Kevin and Lehane for your responses.
> > > > >
> > > > > > From an academic point of view, I agree in
that BSC and TSC
> > > > shouldn't be mutually exclusive. However, managing
multiple schemas
> > > > into embedded devices is sometimes hard to do, mainly
if both schem=
as
>
> > > > don't follow identical mechanisms. Embedded controllers
have limite=
d
> > > > flash space and the UDP parsing must be done in a very
dynamic way.
> > > > Thus, I would prefer to deal with a single schema for
embedded
> > > > devices. That's all. Other more powerful controllers
like opn-max
> > > > could manage (and map) as many schemas as nedded.
> > > > >
> > > > > On the other hand, this kind of discussions could
be addressed in=
a
>
> > > > future thread. At this moment, I just wanted to know
about other xA=
P
> > > > developers currently working (or planning to work) on a
xAP TSC
> > > > implementation.
> > > > >
> > > > > Daniel.
> > > > >
> > > > >
> > > > > --- In
xAP_developer@xxxxxxx<xAP_developer%40yahoogroups.=
com>
> > > > <mailto:xAP_developer%40yahoogroups.com<xAP_developer%2540yahoogrou=
ps.com>>,
> Kevin T<kevin@> wrote:
> > > > >
> > > > >> Gents
> > > > >>
> > > > >> Personaly I have never regarded TSC as a
replacement for BSC. I =
am
>
> > > > sure this
> > > > >> was not the intention.
> > > > >>
> > > > >> I have always regarded TSC more as a better
way of handing analo=
g
> > > > rather
> > > > >> than digital vaules. The handling of analogs
within BSC was alwa=
ys
> a
> > > > >> compromise and TSC was the answer.
> > > > >>
> > > > >> Where I have tried to implement TSC it has
always been alongside
> > > > BSC, and
> > > > >> sometimes even alongside other schema like
xap-temperature. Ther=
e
> is no
> > > > >> reason for the schema to be mutually
exclusive, they can co-exis=
t,
>
> > > > and/or
> > > > >> you coulld chose to tuyrn one or the other off
> > > > >>
> > > > >> Kevin T
> > > > >> (the other Kevin)
> > > > >>
> > > > >> On 22 March 2010 06:49, Lehane Kellett
(g8kmh)<g8kmh@> wrote:
> > > > >>
> > > > >>
> > > > >>>
> > > > >>> Daniel,
> > > > >>> I think one reason for the current lack of
TSC adoption is ther=
e
> > > > are few
> > > > >>> devices supporting it, none public AFAIK.
Hammering out the
> > > > remaining issues
> > > > >>> shouldn't prove too difficult.
> > > > >>>
> > > > >>> A more widescale adoption would, I think,
take xAP adoption to =
a
> > > > new level.
> > > > >>> I don't see why TSC shouldn't be adopted
by Floorplan (James ha=
s
> > > > some hooks
> > > > >>> in already) and other widely used
applications/mappers over tim=
e
> > > > but right
> > > > >>> now there is no motivation to do so.
Chicken and Egg.
> > > > >>>
> > > > >>> Regards,
> > > > >>> Lehane
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> Daniel Berenguer wrote:
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> After reading Kevin's post about the
necessity to migrate to xA=
P
> TSC
> > > > >>> for actual telemetry applications I've
being considering doing
> the
> > > > >>> jump for my recent projects. First of all,
I wanted to do a fir=
st
> try
> > > > >>> on opn-mbs, my Modbus opnode. I didn't
like how data was being
> pushed
> > > > >>> into the BSC text field where data and
units had to coexist mos=
t
> of
> > > > >>> the time. For my own projects, I never add
the units at the end
> of the
> > > > >>> text field because this complicates data
parsing on other BSC
> > > > >>> applications but some other applications
need to know which kin=
d
> of
> > > > >>> data is being transported by any BSC
message. This is what I ca=
ll
> the
> > > > >>> "plug and play" feature. A
temperature controller can understan=
d
> the
> > > > >>> data sent by temperature sensors with very
little programming o=
n
> the
> > > > >>> controller.
> > > > >>>
> > > > >>> Some protocols like J1939, Zigbee and KNX
specify the type of
> data
> > > > >>> transported each time so converting these
data to xAP BSC would
> make
> > > > >>> us consider the following scenarios:
> > > > >>>
> > > > >>> 1. Lose of information. BSC doesn't inform
about the type of da=
ta
> > > > >>> transmitted.
> > > > >>> 2. Add units at the end of the BSC text
field
> > > > >>> 3. Add proprietary field
("units", "type" or whatever else)
> > > > >>>
> > > > >>> As you can see, moving to TSC is something
technically useful I=
MO
> > > > >>> although we should address some pending
issues regarding the
> current
> > > > >>> TSC draft too. However, what bothers me is
that BSC is the most
> > > > >>> implemented schema and abandoning it would
reduce
> interoperability to
> > > > >>> the TSC products. Obviously, we should
combine both BSC and TSC
> > > > >>> schemas, at least during the first years,
in order to guarantee
> > > > >>> interoperability with current BSC
solutions but this is somethi=
ng
> not
> > > > >>> desirable because of the increment of the
xAP code footprint.
> > > > >>>
> > > > >>> Based on the above reasoning, I'd always
vote for enriching xAP
> BSC
> > > > >>> instead of abandoning it regardless of
TSC's advantages.
> > > > >>> Interoperability and the current BSC
implementations are the be=
st
> > > > >>> "heritage" of xAP IMO so we
should take this kind of decisions
> very
> > > > >>> carefully. But instead of starting a new
controversy, I want to
> do a
> > > > >>> simple question to the active xAP
developers:
> > > > >>>
> > > > >>> How many among you are willing to
move/implement TSC into your
> current
> > > > >>> BSC applications in the short term?
> > > > >>>
> > > > >>> I wouldn't want my controllers to become a
TSC island into the
> BSC
> > > > >>> sea. As any other I/O device, they need
interoperability with
> major
> > > > >>> software like HomeSeer, HouseBot, Mr.House
or Xlobby but haven'=
t
> heart
> > > > >>> about any intention to do the jump for
these applications.
> > > > >>>
> > > > >>> Thanks guys for your feedback.
> > > > >>>
> > > > >>> --
> > > > >>> Daniel Berenguer
> > > > >>> http://www.usapiens.com <http://www.usapiens.com>
> > > > >>> http://www.opnode.org <http://www.opnode.org>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------------
> > > > >
> > > > > Yahoo! Groups Links
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
>=20=20
>
--0016e6d77f748851a50484f9d571
Content-Type: text/html; charset=windows-1252
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: 10px 0;
padding: 0 10px;
}
#ygrp-mkp hr {
border: 1px solid #d8d8d8;
}
#ygrp-mkp #hd {
color: #628c2a;
font-size: 85%;
font-weight: 700;
line-height: 122%;
margin: 10px 0;
}
#ygrp-mkp #ads {
margin-bottom: 10px;
}
#ygrp-mkp .ad {
padding: 0 0;
}
#ygrp-mkp .ad a {
color: #0000ff;
text-decoration: none;
}
-->
</style>
<body>
<!-- **begin egp html banner** -->
<br><br>
<!-- **end egp html banner** -->
<div>Kevin & Daniel</div>
<div>=A0</div>
<div>Back in 2007 when the TSC spec first came out I started work on
an app=
called PIDSim. This was a hack of=A0a pre-existing app with the addition o=
f BSC, TSC and xAPTSC message creation, the intention being to add it to
my=
xAPLabs series as an aid to testing. </div>
<div>=A0</div>
<div>I posted a picture here <a href=3D"http://www.netcompsys.co.uk/pidsim.=
jpg">http://www.netcompsys.co.uk/pidsim.jpg</a>=A0.
I got as far as creatin=
g the messages for changes in the analog components and a few people even
h=
ad a play with the app itself.=A0 </div>
<div>=A0</div>
<div>I do remember recieving a couple of what I considered to be
sharp and =
unhelpful remarks at the time and since there seemed to be no great
interes=
t then, I abandoned it an moved on to other things. </div>
<div>=A0</div>
<div>However the app still works and still generartes the messages,
and if =
it is of any help to you please contact me off list</div>
<div>=A0</div>
<div>Kevin T<br><br></div>
<div class=3D"gmail_quote">On 29 March 2010 13:29, Daniel
Berenguer <span d=
ir=3D"ltr"><<a href=3D"mailto:dberenguer@xxxxxxx";>dberenguer@usapie=
ns.com</a>></span> wrote:<br>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px
0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote">
<div style=3D"BACKGROUND-COLOR:
#fff"><span>=A0</span>=20
<div>
<div>
<div>
<p>This is something that we can't postpone IMO. Although I
had expecte=
d a higher interest on this subject, I agree with Lehane in that someone
sh=
ould take the first step and try to implement TSC into a controller. This
w=
ould give us a better idea about the strengths and weakness of TSC in
embed=
ded devices and maybe will inspire other developers as well.<br>
<br>In a few weeks, Kevin H and me are going to work on a TSC
implementatio=
n for opn-mbs. This will give us the opportunity to take a more practical
g=
lance at the issue. We'll come back then with new questions so
we'l=
l be able to start a debate in a proper way.<br>
<br>Daniel.=20
<div>
<div></div>
<div class=3D"h5"><br><br>--- In <a
href=3D"mailto:xAP_developer%40yahoogro=
ups.com"
target=3D"_blank">xAP_developer@xxxxxxx</a>,
"Daniel =
Berenguer" <dberenguer@...>
wrote:<br>><br>> I support Leh=
ane's proposal about re-working TSC. I think that, with some minor
chan=
ges, TSC could become pretty usable, even for embedded devices with
current=
BSC support.<br>
> <br>> Daniel.<br>> <br>>
<br>> --- In <a href=3D"mailto:xA=
P_developer%40yahoogroups.com"
target=3D"_blank">xAP_developer@yahoogroups.=
com</a>, "Lehane Kellett (g8kmh)"
<g8kmh@> wrote:<br>> &=
gt;<br>
> > Kevin,<br>> > I think xAPBSC and TSC
can only co-exist in s=
ome simpler devices - my <br>> > current (only)
implementation is for=
the TOM10 where (a) the code is C# <br>> > .NET and so
space isn'=
;t an issue and (b) the xAPBSC implementation <br>
> > hasn't changed from a previous version. Where the
complexity =
of TSC is <br>> > required then xAPBSC may be a subset,
typically I&#=
39;d expect for <br>> > status/reporting purposes
rather than control=
, although gross control <br>
> > (on/off) could be either.<br>> >
<br>> > Given the st=
atus of TSC and the low number of adopters maybe we should
<br>> > lo=
ok at some revisions or even deprecation of some elements in order to
<br>
> > help adoption?<br>> >
<br>> > Lehane<br>> > <br=
>> > <br>> > <br>>
> Kevin Hawkins wrote:<br>> > &g=
t; <br>> > ><br>> > >
I had always envisaged BSC and TSC =
both existing side by side and<br>
> > > hopefully being supported by nearly all devices.
My hope wit=
h TSC was<br>> > > that it would be sufficiently
similar to BSC th=
at it could share large<br>> > > areas of code
and not really incu=
r any extra overhead in supporting both<br>
> > > rather than just say TSC. In a way TSC being BSC
with extra =
parameters<br>> > > and a relaxation of some
constraints on existi=
ng ones (eg decimal<br>> > > places, negative
values etc). Obvious=
ly by it's nature TSC will be<br>
> > > more involved than BSC.<br>>
> ><br>> > > =
At this stage I'm feeling we haven't quite achieved that
but maybe<=
br>> > > others don't agree with an
intention ever to try and =
do so ? Having<br>
> > > played a little with TSC it doesn't
present that commona=
lity - maybe<br>> > > that's the nature
of the beast - but I h=
ave a few reservations about the<br>> > > schema
and had great dif=
ficulty in creating a sensible model to<br>
> > > implement it alongside BSC. Lehane - have you
actually got b=
oth BSC<br>> > > and TSC fully implemented in
your embedded device=
s ?<br>> > ><br>> > >
K<br>> > ><br>> > &g=
t; On 22/03/2010 17:29, Daniel Berenguer wrote:<br>
> > > > Thanks Kevin and Lehane for your
responses.<br>> >=
; > ><br>> > > > >
From an academic point of view, I a=
gree in that BSC and TSC <br>> > >
shouldn't be mutually exclu=
sive. However, managing multiple schemas <br>
> > > into embedded devices is sometimes hard to do,
mainly if bot=
h schemas <br>> > > don't follow
identical mechanisms. Embedde=
d controllers have limited <br>> > > flash space
and the UDP parsi=
ng must be done in a very dynamic way. <br>
> > > Thus, I would prefer to deal with a single
schema for embedd=
ed <br>> > > devices. That's all. Other
more powerful controll=
ers like opn-max <br>> > > could manage (and
map) as many schemas =
as nedded.<br>
> > > ><br>> > >
> On the other hand, this kind of =
discussions could be addressed in a <br>> > >
future thread. At th=
is moment, I just wanted to know about other xAP <br>>
> > develop=
ers currently working (or planning to work) on a xAP TSC <br>
> > > implementation.<br>> >
> ><br>> > > >=
; Daniel.<br>> > > ><br>>
> > ><br>> > > &=
gt; --- In <a href=3D"mailto:xAP_developer%40yahoogroups.com";
target=3D"_bl=
ank">xAP_developer@xxxxxxx</a> <br>
> > > <mailto:<a href=3D"mailto:xAP_developer%2540yahoogroups.c=
om"
target=3D"_blank">xAP_developer%40yahoogroups.com</a>>,
Kevin T<k=
evin@> wrote:<br>> > >
><br>> > > >> Gents<br=
>
> > > >><br>> >
> >> Personaly I have never r=
egarded TSC as a replacement for BSC. I am <br>> >
> sure this<br>=
> > > >> was not the
intention.<br>> > > >><b=
r>
> > > >> I have always regarded TSC more
as a better way of =
handing analog <br>> > >
rather<br>> > > >> than di=
gital vaules. The handling of analogs within BSC was always
a<br>> > =
> >> compromise and TSC was the answer.<br>
> > > >><br>> >
> >> Where I have tried to im=
plement TSC it has always been alongside <br>> >
> BSC, and<br>>=
; > > >> sometimes even alongside other schema
like xap-tempera=
ture. There is no<br>
> > > >> reason for the schema to be
mutually exclusive, the=
y can co-exist, <br>> > >
and/or<br>> > > >> you co=
ulld chose to tuyrn one or the other off<br>> >
> >><br>
> > > >> Kevin T<br>>
> > >> (the other Kevin=
)<br>> > > >><br>>
> > >> On 22 March 2010 06=
:49, Lehane Kellett (g8kmh)<g8kmh@> wrote:<br>>
> > >>=
<br>
> > > >><br>> >
> >>><br>> > >
&g=
t;>> Daniel,<br>> > >
>>> I think one reason for th=
e current lack of TSC adoption is there <br>> >
> are few<br>> =
> > >>> devices supporting it, none
public AFAIK. Hammering =
out the <br>
> > > remaining issues<br>> >
> >>> shouldn'=
t prove too difficult.<br>> > >
>>><br>> > > >=
;>> A more widescale adoption would, I think, take xAP
adoption to a =
<br>
> > > new level.<br>> > >
>>> I don't see wh=
y TSC shouldn't be adopted by Floorplan (James has
<br>> > > s=
ome hooks<br>> > > >>> in
already) and other widely used =
applications/mappers over time <br>
> > > but right<br>> > >
>>> now there is no mot=
ivation to do so. Chicken and Egg.<br>> > >
>>><br>> &=
gt; > >>> Regards,<br>> >
> >>> Lehane<br>
> > > >>><br>>
> > >>><br>> >
>=
; >>><br>> > >
>>> Daniel Berenguer wrote:<br>&g=
t; > > >>><br>> >
> >>><br>> > > =
>>><br>
> > > >>> After reading
Kevin's post about the necess=
ity to migrate to xAP TSC<br>> > >
>>> for actual telemet=
ry applications I've being considering doing the<br>>
> > >=
>> jump for my recent projects. First of all, I wanted to do
a first =
try<br>
> > > >>> on opn-mbs, my Modbus
opnode. I didn't like=
how data was being pushed<br>> > >
>>> into the BSC text=
field where data and units had to coexist most of<br>>
> > >&g=
t;> the time. For my own projects, I never add the units at the end
of t=
he<br>
> > > >>> text field because this
complicates data parsin=
g on other BSC<br>> > > >>>
applications but some other a=
pplications need to know which kind of<br>> > >
>>> data =
is being transported by any BSC message. This is what I call the<br>
> > > >>> "plug and
play" feature. A temperatur=
e controller can understand the<br>> > >
>>> data sent by=
temperature sensors with very little programming on the<br>>
> > =
>>> controller.<br>
> > > >>><br>>
> > >>> Some protocols l=
ike J1939, Zigbee and KNX specify the type of data<br>>
> > >&g=
t;> transported each time so converting these data to xAP BSC would
make=
<br>
> > > >>> us consider the
following scenarios:<br>> &g=
t; > >>><br>> > >
>>> 1. Lose of information.=
BSC doesn't inform about the type of data<br>>
> > >>&g=
t; transmitted.<br>
> > > >>> 2. Add units at the end
of the BSC text field<b=
r>> > > >>> 3. Add proprietary
field ("units", =
"type" or whatever else)<br>> >
> >>><br>> &=
gt; > >>> As you can see, moving to TSC is
something technicall=
y useful IMO<br>
> > > >>> although we should
address some pending issues =
regarding the current<br>> > >
>>> TSC draft too. However=
, what bothers me is that BSC is the most<br>> >
> >>> im=
plemented schema and abandoning it would reduce interoperability
to<br>
> > > >>> the TSC products.
Obviously, we should combine =
both BSC and TSC<br>> > >
>>> schemas, at least during th=
e first years, in order to guarantee<br>> > >
>>> interop=
erability with current BSC solutions but this is something not<br>
> > > >>> desirable because of
the increment of the xAP c=
ode footprint.<br>> > >
>>><br>> > >
>>>=
; Based on the above reasoning, I'd always vote for enriching xAP
BSC<b=
r>
> > > >>> instead of abandoning
it regardless of TSC'=
s advantages.<br>> > > >>>
Interoperability and the curre=
nt BSC implementations are the best<br>> > >
>>> "he=
ritage" of xAP IMO so we should take this kind of decisions
very<br>
> > > >>> carefully. But instead
of starting a new contro=
versy, I want to do a<br>> > >
>>> simple question to the=
active xAP developers:<br>> > >
>>><br>> > > &g=
t;>> How many among you are willing to move/implement TSC
into your c=
urrent<br>
> > > >>> BSC applications in the
short term?<br>> >=
; > >>><br>> > >
>>> I wouldn't want my c=
ontrollers to become a TSC island into the BSC<br>> >
> >>&g=
t; sea. As any other I/O device, they need interoperability with
major<br>
> > > >>> software like HomeSeer,
HouseBot, Mr.House or X=
lobby but haven't heart<br>> > >
>>> about any intent=
ion to do the jump for these applications.<br>> >
> >>><b=
r>
> > > >>> Thanks guys for your
feedback.<br>> > >=
; >>><br>> > >
>>> --<br>> > >
>>=
> Daniel Berenguer<br>> > >
>>> <a href=3D"http://www.=
usapiens.com/" target=3D"_blank">http://www.usapiens.com</a>
<<a href=3D=
"http://www.usapiens.com/";
target=3D"_blank">http://www.usapiens.com</a>>=
;<br>
> > > >>> <a href=3D"http://www.opnode.org/";
target=3D"_b=
lank">http://www.opnode.org</a>
<<a href=3D"http://www.opnode.org/"; targ=
et=3D"_blank">http://www.opnode.org</a>><br>>
> > >>><=
br>> > > >>><br>
> > > >>><br>>
> > >>><br>> >
>=
; >>><br>> > >
>><br>> > >
><br>> &g=
t; > ><br>> > >
><br>> > > > ----------------=
--------------------<br>
> > > ><br>> > >
> Yahoo! Groups Links<br>> >=
> ><br>> > >
><br>> > > ><br>>
> > =
><br>> > > ><br>>
> ><br>> > ><br>>
>=
;<br>
><br><br></div></div>
<p></p></p></div>
<div style=3D"MIN-HEIGHT: 0px; COLOR:
#fff"></div></div></blockquote></div>=
<br>
<!-- **begin egp html banner** -->
<br>
=20=20=20=20
=20=20=20=20
<br>
<!-- **end egp html banner** -->
<div width=3D"1" style=3D"color: white; clear:
both;"/>__._,_.___</div>
<!-- Start Recommendations -->
<!-- End Recommendations -->
<!-- **begin egp html banner** -->
<img src=3D"http://geo.yahoo.com/serv?s=3D97476590/grpId=3D9629476/grpspI=
d=3D1705007709/msgId=3D2129/stime=3D1272108479" width=3D"1"
height=3D"1"> <=
br>
<!-- **end egp html banner** -->
=20=20
<!-- **begin egp html banner** -->
<br>
<div style=3D"font-family: verdana; font-size: 77%; border-top: 1px
s=
olid #666; padding: 5px 0;" >
Your email settings: Individual EmailTraditional <br>
<a href=3D"http://groups.yahoo.com/group/xAP_developer/join;_ylc=3DX3=
oDMTJmcDA0cGhnBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5B=
HNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNzIxMDg0Nzk-">Change settings
via the We=
b</a> (Yahoo! ID required) <br>
Change settings via email: <a href=3D"mailto:xAP_developer-digest@yah=
oogroups.com?subject=3DEmail Delivery: Digest">Switch delivery to
Daily Dig=
est</a> <a href =3D "mailto:xAP_developer-fullfeatured@xxxxxxx?su=
bject=3DChange Delivery Format: Fully Featured">Switch to Fully
Featured</a=
> <br>
<a href=3D"http://groups.yahoo.com/group/xAP_developer;_ylc=3DX3=
oDMTJkNWZsZWRiBF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5B=
HNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjcyMTA4NDc5">
Visit Your Group=20
</a>
<a href=3D"http://docs.yahoo.com/info/terms/";>
Yahoo! Groups Terms of Use
</a>
<a href=3D"mailto:xAP_developer-unsubscribe@xxxxxxx?subject=
=3DUnsubscribe">
Unsubscribe=20
</a>=20
<br>
</div>
<br>
<!-- **end egp html banner** -->
<div style=3D"color: white; clear:
both;"/>__,_._,___</div>
</body>
</html>
--0016e6d77f748851a50484f9d571--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|
