[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