[Tinyos-host-mote-wg] [Tinyos-2.0wg] 06/08/2005 Telecon Notes

Kristin Wright l.kristin.wright at gmail.com
Wed Jun 15 13:17:05 PDT 2005


-------------- next part --------------

Notes from 06/08/2005 TinyOS 2.0 Working Group 

06/08/2005 Agenda
------------------
- Resolution on what layer AM belongs to
- Status 
- NesC packages 

06/08/2005 Action items
---------------------------
- David Gay: communicate w/crossbow to encourage continued participation
- Phil Levis: send out pointer to example of NesC packages in use (this 
  may have been dgay)

06/15/2005 Agenda
------------------
Not discussed

06/01/2005 Discussion Notes
----------------------------------------------------------

AM layer
---------
- Group decided to put AM in the lower layer (radio) and 
  see how the implementation and usage play out from there

Status 
-------
- It was noted that xbow was absent from the last couple meetings and 
  their help would be very appreciated in testing the CC2420 radio stacks,
  among other things; there was also some concern as to where the 
  micaz status and whether it was going to make it into 2.0; dgay (David
  Gay) will try to encourage more participation 

Packages in NesC
-------------------
- See introductory mail thread here:
  https://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-June/000915.html
- dgay (David Gay, Intel Research - Berkeley0: big question: do we need them? 
  - pro: names get horribly long and hard to remember in 2.0 (also true in 1.x) 
  - package names are expected to closely follow the directory tree naming/structure
- phil (Phil Levis, UCB): one example he's come across in coding come higher-level (oski-level) 
  components is Timer: what does he call it in oski? There's already a timermilliC	
  in HIL so he ends up with this name: oskiTimerMilliC. With a flat namespace, have to 
  compress into a big string 
- vlado (Vlado Handziski, TU Berlin): feels it is dangerous to do something to endanger easy shadowing 
  of components;
  - phil: agrees: Cory (not present) mentioned that he must need to be able 
    to shadow components 
- vlado: afraid we're going to overengineer
- dgay: has a solution that hopes will be as easy as current shadowing 
    mechanism; involves placing a description in a dir that says "this dir is shadowning
    this other dir"
- phil: namespace above HIL much larger than under and managing it is going
  to be challenge; package name in oski (looking at tep 3) (dgay: decided not
  to do that)
- vlado: currently we can modify components used by rewiring or 
  change include paths; when you have packaging, adding a
  3rd way to import something. how do I shadow only a subset of the package?
- dgay: it's more a change in how include path works; shadowing will work the 
  same way as currently
- phil: the win is that when you name a component not flat
- vlado: how will scoping work?  
- dgay: scoping - when in package x, can use shorter names for things in 
   that package and there's some kind of import facility for getting short names
   for other packages; can use long names everywhere (no change from now)
- vlado: how about scoping errors? 
- culler (David Culler, UCB)
  what to understand: have 3 translation mechs: configuration, search paths,
  what am i gaining?
- dgay: reiterated that the main win is to  allow not to go crazy 
  w/java.lang.vector (analogy) everywhere
- culler: not just long to short (can do w/defined)
- dgay: want scoped names
- culler: so we want want a locally scoped short name for a long-structured fullname
  - we want want hierarchical long names and scoped short names
- dgay: to what extent do we need these long names? Or can we get away with 
  a few long names? 
- culler: not convinced that the length is important, but the hierarchy 
  is important
- phil: motivation for packages has little to do with the layers below but
  the stuff above; ex: oski* OskiTimerMilliC/OskiAMSender; what if I  
  want to have greater division: OskiLowPowerTimerMilleC -- 
- dgay: still have a global name problem; ex: Coordinator in two subsystems
- phil: if 2 people both want to use the same name, there's nothing you can do
- dgay: thinking internally; A.Coordinator B.Coordinator for public
- someone (Phil) will write up an example in code and send it out

  
-------------- next part --------------
_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg


More information about the Tinyos-host-mote-wg mailing list