One of the interesting aspects of NesC is that it doesn't enforce any
specific kind of encapsulation of interfaces. That is, an application
component can "poke through" the various layers below it to get at an
interface provided by a deeper underlying component. In this case you
propose to provide a CC2420-specific signal when a message is about to
be transmitted. I don't see a problem with that but I am concerned
about the divergence of the implementation from the TEP, and what it
means for layering in general (for example, above other, non-CC2420
radio stacks).
One of the oft-mentioned problems for non-core developers is that
changes like this are introduced without being well-documented,
leading to a tangled mess of interfaces, and potentially unexpected
behaviors. My understanding was that the TEP process was intended to
reign in that sort of volatility, no matter how expedient the change
might be. So I guess this comes down to a more philosophical question
of which changes to a core system component require vetting through
the TEP process and which do not.
On Feb 7, 2008, at 7:13 PM, Philip Levis wrote:
On Feb 7, 2008, at 6:00 AM, David Moss wrote:
Matt and Phil -
This is meant to serve only as a private interface within the
CC2420 stack
right now, not an interface provided by the ActiveMessage façade.
After
all, once the interface is provided by ActiveMessage, it is no
longer a
private CC2420-specific interface.
This is absolutely not a CTP or MultiHop protocol changing
interface, since
that would make those libraries platform dependent, which is bad.
This is
also not an LPL interface. Rather, the point of this interface is
to simply
signal an event at the top of the stack that says the radio is
sending a
message. Your application can do what it wants with that event.
For developers who want CTP + LPL on a CC2420 platform, this single
notification event gives them the ability to make it happen *right
now*
without modifying any libraries. No modifications to CTP, no
modifications
to LPL, no modifications to the radio stack, and nearly 0 cost.
You're correct: we should document this interface in the CC2420
TEP, or add
this to some other TEP to standardize it across radio stacks. A
second
direction would be to continue adding onto the LowPowerListening
interface
to make each outbound message use your local LPL settings, but I
would be
hesitant to make those kinds of changes without a lot of backing.
Oh, I think I misunderstood. I thought you were suggesting a change
to the CTP code in CVS.
Phil
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
