[Tinyos-2.0wg] 30/8 conf call notes

[henri dubois-ferriere]

attached.
-------------- next part --------------
henri, kevin, david gay, ralph, jonathan, ?someone else from AR?

dgay: we go over TEP108 today

henri: In S3.1, what is the rationale for returning EBUSY upon multiple requests
       from same client ? From last sentence in para, this appears to be
       only for the purpose of avoiding mis-behaving clients from filling up
       queue. But if this is the purpose, then one could also just return
       SUCCESS, but not insert anything into the queue, with multiple repeated
       requests being "merged" into the first one.

kevin: It's also as a convenience, e.g a client can check if it has already
       requested the resource and does not need to keep track of it itself.
       Will point out this use of EBUSY in the TEP.

henri: Appendix A:
       Current phrasing may make it sound (to users unfamiliar with @xxxonce()
       annotations) that the presence @exactlyonce() is the reason why this
       resource dedicated. Should point out that the @exactlyonce() is there
       for clarity and to get warnings, and is a good practice, but that this
       could still be a dedicated resource without the annotation.
       Also, nesc does not *enforce* it (as the TEP says), it simply issues a
       warning.

kevin: ok       


dgay: typos, missing parens in components

      3.5 has a bunch of missing words, typos, etc.
      
      last part of 2.3 (shared components) could be made into it's own
      paragraph

      3.1 doesn't clearly describe that immediateRequest not followed by
      granted() and that you get resource right away.

      in general, many references to using unique() and fairly sophisticated tricks
      that might be confusing to casual/new users (wrapping resources, generic
      component, etc, ). could remove details, make a high-level statement,
      and point to code in appendix.

      Resourceconfigure: should say that unconfigure must be called after
      release and *before next configure* call (latter half currently not
      said explicitly).

kevin: sure, ok with all above.

      ResourceRequested (3.3): A has resource, B and C requested it.
      A releases, B gets it. Does be get a requested() event to indicate that
      someone else is waiting?
      Propose that you immediately get a requested() after a granted() event.

kevin: makes sense. need to think this over.

dgay:  Appendix B is fairly complicated, might want to have a disclaimer
       saying that this is rather tricky for novice nesc users and point to relevant
       part of phil's manual.

kevin: ok. will also get a novice nesc user to read through and see how
       understandable he/she finds it.

kevin: will send out a revised version next week that addresses most above
       comments, for non-obvious one (ResourceRequested with A,B,C) will think about
       and send thoughts

dgay:  discussion on storage TEP on mailing list. what do people think.
       
jhui:  didn't see all of it yet. will exchange a few emails with dgay on
       storage tep open issues.


jhui:  how close is the code in tree to code in tep?
       even if things in sync, will be problem if tree changes.

dgay:  in long term, we can simply point to "tinyos version 2.0.x".
       or point to a particular revision.


dgay: at some point we should discuss on the mailing list what to do about
      this problem in general. maybe we should always phrase things as "this
      is how the code could be done in a somewhat simplified version; full
      version is in repository". This might require examples to be somewhat
      more self-contained.