PeerHood & UMSIC Meeting 2008-09-23

10-12 % 14-16

Topics

Define PeerHood status

  • PeerHood specification !
    • PeerHood Design document (UML)?
    • Plugin API
    • Application API ← plugin appl. API
  • Existing projects → Use Cases → Requirements (features) → Specification
  • Projects (VIVIAN, PTD, UMSIC)
  • Concepts (ME)
  • Summer projects (NFS, Multihop, Social Network, Remote monitoring, FAME linkitys (Java API))
  • Applications (Chat/Kazaa)
  • Neighborhood info (Arto)
  • Use Cases [uusi kandityö Reverse Engineering…]
  • Requirements
  • Other Dependant projects (peerhood development resources xx %) ← Specification (What PeerHood is?) ← PeerHood development guidance
  • PeerHood Appendixes and Extensions ; Core in specification !
  • Resources
    • Hevi (Task: Internal PeerHood “project”→ määrittelee tarpeet jota kautta roadmap / priorisointi)
    • Arto (Task:…
    • Were (Task: context aware security
    • N.N
    • N.N
    • Tommi (UMSIC requirement specification)
    • Jussi (Porting PeerHood to Maemo)
    • UMSIC functional architecture (PeerHood + mitä päälle)
    • “PeerHood configuration module” tehty case by case
  • Action point #1: new devices (BT), bluetooth measurements, Arto
  • Action point #2: enhanced 'intelligence', neighborhood info algorithm, Arto+Pegax
  • Action point #3: wireless characteristics (performance) analysis and development, Pegax+
  • Minor Action point: connection management development

PeerHood & UMSIC relationship

Tasks to do to improve PeerHood

Priority Class [1..5] → Hevi's Action Point

  • UMSIC needs / requirement [5]
  • PeerHood codehosting environment (reactor & thread pool) [2]
  • WLAN/Bluetooth/GPRS… test/demo/sim environment (for development) [3] →
    • Device
    • Software
    • What is required ?
    • What is available ?
  • PeerHood Simulator [3]
  • simulator plugin?
  • virtual connections / interfaces
  • in order to enable more dynamic handling of interfaces
  • Use Case works (incl. interfaces) → Specification [5]
  • Test Cases [3]
  • Fault Tolerance / Error Management [4]
  • Resource Management (power → energy efficiency) [2]
    • proactivity vs. reactivity (resource-based)
  • API
  • Configuration [hevi will do it !]
  • PeerHood usability, control, forensics (debuglogging), visualisation (real-time GUI),
  • Context aggregation, Context Management…
  • Security
    • Authenticating the connections, validation that the handover goes to proper device
    • Applications using PeerHood should be able to select which security options are used
    • Security services for applications
      • Certificate validation
      • Secure connections
  • Privacy
    • What kind of information peerhood leaks about the device and its owner
    • How to protect the privacy of the device owner

Resources to PeerHood tasks

More ..

Other Topics

Project archivist

  • Situation is that on PeerHood there is done many works, but results are lost somewhere.
  • Results from projects should be archived into well know repository (tutkimus.it.lut.fi)
  • Suggestion is that for each project (PeerHood and any comlab project) there is named a project archivist.

Project archivist:

  • Is responsible to have up to date contact information.
  • Is responsible to have access to repository to store work results.
  • Is responsible to maintain project wide and comlab wide list (or index) in wiki about works.
  • Is not responsible to know which works is done or will be assigned. It is project manager, professor or instructor responsible to guide the work maker to deliver results to the project archivist.
  • Index to Wiki-pages
  • PEERHOOD (PHei)
  • UMSIC (KH)
  • CANDIDATE (JP) / MASTER WORKS (JP)

NEXT MEETING

  • by default once in month (21.10)