[net2-wg] Proposal for dissemination structure and interfaces

[Philip Levis]

On Sat, 2005-12-17 at 21:03 -0500, Kyle Jamieson wrote:

> This is a nit-pick, but why not two configs, say DisseminatorC
> and DisseminationC, which each provide interface DisseminationUpdate
> and interface DisseminationValue, respectively?  I guess the
> motivation behind this is clarity for users.  Or, is there perhaps a
> situation where an app might use both DisseminationValue and
> DisseminationUpdate? (I can't think of one..)

I started hacking out these interfaces and remembered why the proposal
has one configuration. It has to do with instantiation. Basically, the
question comes up of who instantiates the module which actually
allocates the storage for the value. You only want one instantiation
(there should only be one copy). In the proposal we made, the state is
allocated in DisseminatorP, not in the DisseminationEngine, as there's
no way to allocate the state within the latter.

If you have separate Update and Value components, then you need to
orchestrate the underlying instantiation. The reason this is hard with
generics is because the component's name is local to the configuration
that is instantiating it. There's no way to say "instantiate something
named this unless something with the same name already exists." The one
way you can do it is to create a configuration that instantiates within
it, thereby creating a global name that everyone can refer to. E.g.:

configuration TxPowerC {
  provides interface DisseminateValue<uint16_t> as V;  
  provides interface DisseminateUpdate<uint16_t> as U;
}
implementation {
  components new DisseminatorC(uint16_t, DIS_TX_POWER) as C;

  V = C;
  U = C;
}


But this then requires the user to define a new component for a value,
rather than just instantiating a generic within another component. I.e.,
it requires a new file, rather than just a few lines of code.

This is probably a bit confusing. It's an example of one of nesC's
limitations. But I also might be misinterpreting Kyle's question. I
don't know how you could achieve Kyle's suggested interface without
going through some generic-singleton contortions. Does anyone know of a
way to do so?

Phil