[Tinyos Core WG] tep comments

[Janos Sallai]

This is in response to some of the comments in today's T2 Core WG
meeting on the time stamping/sync TEP drafts.

> Why is there a HAL requirement? Why not just HIL? (both TEPs)
According to TEP 116 (HIL, section 3), a platform's ActiveMessageC has a
fixed signature: 8 provided interfaces, no more, no less. If the
platform's ActiveMessageC is not allowed to be extended with additional
provided interfaces, which HIL-level component should provide packet
times tamping/sync? (A similar problem also comes up with providing LPL
functionality, requiring #ifdefs to wire in the platform-specific HAL
component in HIL-compliant portable code.)

According to TEP 116 (HAL Requirements, section 5), the XActiveMessageC
components are part of the HAL, not the HIL. The time stamping/sync TEPs
should state that the XActiveMessageC components MUST provide the time
stamping/sync interfaces. Where should the user look for them otherwise?
That's the reason why I have the HAL requirements section in there.

> after clear is called, ``isSet`` MUST return FALSE? (timestamping TEP)
What should be the semantics of clear? What is the semantics of
Packet.clear in general? Are ``set`` and ``clear`` really needed to be
part of this interface?

> isSet -> isValid (timestamping TEP)
This appears to be a good idea. Also, ``get()`` will be renamed
``timestamp()``, to be in sync with the rest of the *Packet interfaces.

> Why is all of the statement of data  representation in message_t?
(timestamping TEP)

This ensures that copying a message_t copies all timestamping related
information. In fact, it is a good idea to drop this requirement and
restrict the TEP to the description of the interfaces and the
corresponding functionality.

> "Packet timestamping related metadata fields
> SHOULD NOT be accessed directly by higher-level
> application components, only through the PacketTimeStamp
> interface(s)."
> Why SHOULD NOT? (timestamping TEP)

Because the implementer of the radio stack may store the timestamps in a
different form (e.g. different precision, width, etc.) than what a
particular PacketTimeStamp interface offers. E.g. the iris
implementation uses microsecond precision timestamping internally, and
converts them on the fly to TMilli, when a
PacketTimeStamp<TMilli,uint32_t> call comes. This is restriction on
directly accessing the timestamping related metadata fields is
particularly important when a particular radio stack implements higher
precision timestamping (beside the TMilli precision).

We may want to drop this message_t section altogether. Is anybody
against dropping it?

Janos