[Tinyos-devel] Proposed interface for Nucleus attributes, events, and commands

Stanislav Rost stanrost at csail.mit.edu
Wed Feb 16 16:59:52 PST 2005


Gil,

Please see below.

On Wed, 2005-02-16 at 16:28 -0800, Gilman Tolle wrote:
> > Do you think that perhaps Nucleus events etc. should be a property of
> > interfaces, rather than modules?  That seems to make a bit more sense in
> > many cases, although it might require more language support.
> 
> I'm not sure what you mean. A Nucleus attribute must be made available
> by some module containing actual code, just like a Nucleus event or
> command only has meaning to a module.

True.  But interfaces abstract away the functionality that could be
offered by different implementations, and it seems that many
implementations of interfaces may share the same exportable attributes.
For example, imagine a routing interface TreeRouting.  Should all chunks
of code that "provide" "interface TreeRouting" have to declare that they
are exporting the Nucleus attribute TreeDepth individually, or can we
just add that to the definition of the TreeRouting interface once,
and explicitly expect all implementations to provide it?

> If you want to send something of variable length, perhaps you could
> typedef a structure containing a char array large enough to contain
> the largest data item you would send, set the type of the event to be
> that type, and then manage the storage yourself. This approach
> wouldn't save any bandwidth or flash space, though, because you have
> no way of telling the other side that "this time, it's smaller."

Precisely.  Maybe this could be achieved by an additional Nucleus
interface for setting/getting blob attributes.

> Hmm. It may be easier to learn if users can build an analogy between
> TinyOS events from components to other components and Nucleus events
> from a mote to a remote host. Think of it as an "RPC" approach -- the
> application programmer isn't really supposed to be constantly reminded
> of the fact that it's not a local function call.

The semantics of an RPC call and a local function call are quite
different.  Fundamentally, the differences stem from the fact that
there's no fate sharing, synchronization, or shared context between the
"caller" and the "callee."  On one hand, I agree with your point that
using nearly the same syntax makes transition to RPC intuitive.  On
another hand, I also see the value in making the nomenclature
distinguish between local and remote procedure calls and events.

Stan



More information about the Tinyos-devel mailing list