Re: Comments about TSC

["estratosapiens" <dberenguer@xxxxxxxxxxxx>]

4. I'd prefer to do

unit=(unit designation)
-- desirable

rather than

unit=(unit designation)
-- mandatory

Thus, instead of doing unit=arb, the sender wouldn't include this field in
the body. This is a way of compacting information a little more, mainly if
my second suggestion gets somehow accepted :-)

Daniel.

--- In xAP_developer@xxxxxxx, Daniel Berenguer <dberenguer@...>
wrote:
>
> Following Kevin's call-up request, I've revisited the TSC (v.42)
> specification draft and have found some points that I would like to
> discuss here:
>
> 1. TSC.query vs TSC.request
> The document mixes both classes so I understand that it's an error.
> Which is the correct class?
>
> 2. TSC for numeric values - BSC for states
> I understand that BSC can still be used for many applications but I
> believe that TSC should be able to manage binary states too.
> Otherwise, we'll be force to do dual-implementations almost in any
> device. BSC's main strengths are interoperability and the fact that
> it's a common schema for all. I agree that TSC is a more complete
> schema that could replace BSC for most applications but having to
> manage TSC for numeric and BSC for binary is a nonsense in my opinion.
> Why not using value=on/off in TSC too? From my point of view, we need
> simple mechanisms capable to do complex things. One schema for all is
> perfect for gateways and embedded controllers. Otherwise, we'll have
> to manage with queries/commands from different schemas, send
> duplicated events/infos, ... I also agree that we'll have to keep BSC
> for backward compatibility in current designs but once TSC will be
> widely adopted, TSC is a perfect candidate for becoming the main xAP
> interoperable schema for control and telemetry applications.
>
> 3. Response to TSC.cmd resets
> The specification states that the response to a TSC.cmd (counter)
> reset has to be a TSC.info after having reseted the counter. This
> breaks BSC's command/event query/info mechanisms and, will force us to
> manage a exception when receiving RESET commands. Why not sending a
> TSC.event after reseting the counter? Reseting a counter means that
> the endpoint will change its value (if not 0 before that).
>
> There are a lot of common points between BSC and TSC and I appreciate
> this as it will simplify the adoption of the later schema. On the
> other hand, all my suggestions are targeted to simplify the
> implementation (lines of code and processing speed) and give more
> power to TSC. Instead of creating a new schema, I'd have preferred to
> enrich BSC with new fields but the creation of TSC is something good
> because we have now the opportunity to customize this schema for M2M
> apps. On the other hand, implementing new protocosl or schemas is
> something time-costly so we'll have to be very precise and effective
> in our work.
>
> I vote for one schema for all in the M2M area. TSC for M2M and BSC for
> basic home automation stuff. Isn't it too late for coming here with
> such arguments?
>
> Thanks for your time,
>
> --
> Daniel Berenguer
> http://www.usapiens.com
> http://www.opnode.org
>




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