Re: Re: xAP TSC - A callup request :-)

[Kevin Hawkins <yahoogroupskh@xxxxxxxxxxxxxx>]

It's certainly not too late Daniel,  I think we have to have a few
real
implementations of TSC to see if it is actually fit for purpose and then
we can look to ratify and promote it more.

It was surprising how awkward even a simple schema like BSC became as
little nuances crept in , and of course this was partly due to people
trying to use it for purposes that it wasn't intended for.   TSC is very
heavilly based on BSC and so I'm kinda hoping that people who implement
TSC will also be able to support BSC without too much extra effort, and
vica versa. Certainly the core should be the same.  As to whether BSC
will, or should, eventually be replaced by TSC I'm not sure... maybe
over time but I had assumed they'd both continue to be used

There are some other aspects we need to address as well - including
implementing relative changes eg +10% and multiple choice / enumerated
devices and perhaps some sort of menu driven type mode, that may be
another schema derived from BSC.   Edward has a way of integrating
choice devcies within BSC which I use too - but it's non standard so we
haven't promoted it too much.

Whilst the true power of xAP comes from the ability to abstract complex
device functionality into schema I also recognise that the simple schema
- specifically BSC has been a great sucess and agree that we should
refine and expand this simple schema adoption to be both suitable and
easy to be adopted.

So let's get the discussion opened and get some devices and controllers
using the initial TSC proposal and see where we can refine it.

K




tratosapiens wrote:
> Hi Kevin,
>
> I can't speak for others but I was waiting for a wider adoption of TSC
before doing the jump :-)
>
> Anyway, I agree that xAP applications will never adopt TSC if no
device is using this schema so it's maybe time to do something on this
issue. I could try to work on a TSC implementation for my new designs
(opn-mbs, ...) as a way of getting in touch with this new schema. Later,
once TSC will be ratified, I could port the work to older designs (opn-one
and opn-max).
>
> I believe that TSC brings some important improvements to the
control&monitoring scenario with regards to the old BSC schema. On the
other hand, maintaining multiple protocols/schemas in an embedded device is
something costly in my opinion. This was my case for the first versions of
opn-one and opn-x10 where xAP BSC, xAP X10 and xPL shared a common place in
both gateways. Later, I decided to switch to xAP BSC only because it was
far easier to maintain and simpler to understand by non-xAP people. This is
the key in my opinion, xAP needs to be something easy to understand and
wasy to work with.
>
> There are some other features about TSC that would need to be
reconsidered IMHO and I'll try to address these points from a different
thread. I understand that TSC (v42) is just a draft so I'll try to
introduce my point of view (if it's not too late...)
>
> Regards,
>
> Daniel.
>
>
> --- In xAP_developer@xxxxxxx, Kevin Hawkins <yahoogroupskh@...>
wrote:
>
>> We have a bit of a Catch22 situation with xAP TSC.    Until we
have
>> supporting applications then people don't want to write data
sources and
>> vica versa and we can't ratify TSC into xAPTSC until it has some
real
>> world experience...   Hence xAPBSC is being abused as non
appropriate
>> data is shoehorned in, aprticularly by representing numeric data
as a
>> text device.   So here's a call to xAP Developers to add support
for TSC
>> within their existing applications and hopefully it will become as
>> successful as BSC.
>>
>> Here's a copy of part of my response to a xAP Automation list post
>>
>>    K
>>
>> There is a bit of 'chicken & egg' here and so it is worth
trying to see
>> if we can get better support for TSC within the key xAP
applications -
>> especially the ones that already directly support BSC , as most of
the
>> work is already done.
>>
>> I know Daniel had mentioned he would look towards supporting TSC ,
and
>> it is particularly well suited towards 1-wire applications ,
although I
>> would recommend that BSC remains supported , at least
transitionally.
>> Without such widespread adoption TSC will remain sidelined and BSC
>> abused instead.   Also there are few test applications to develop
>> against which doesn't help people like Mikko.   I remember KevinT
has
>> some however and Lehane uses TSC extensively in his home project.
>>
>> So I'll revisit my contributions and see what I can do here and
>> hopefully a couple of others will too.    Many applications will
already
>> handle TSC as a generic schema as well but having the plug and
play
>> integration in the same way that we have with TSC would be far
preferable
>>
>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>



------------------------------------