Cloud4all WP103 2014-10-02

From wiki.gpii
Jump to: navigation, search

Back to meetings list

Time and date

Important Information for the Meeting

This is a meeting of WP103 within the European Project Cloud4All. However, the minutes of the meeting will be made available to the public to allow people outside Cloud4All to follow our thoughts. If, in the meeting, you want to share confidential information that should not appear in the public minutes, you need to state so in the meeting. This is in line with the Cloud4All Consortium Agreement, section 10.

Please connect to the audio using gotomeeting:

1. Please join my meeting. https://global.gotomeeting.com/join/619028605

2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone.

  • United States: +1 (213) 493-0618
  • Australia: +61 2 8355 1036
  • Austria: +43 (0) 7 2088 1036
  • Belgium: +32 (0) 28 08 4345
  • Canada: +1 (647) 497-9372
  • Denmark: +45 (0) 69 91 89 24
  • Finland: +358 (0) 942 41 5788
  • France: +33 (0) 170 950 586
  • Germany: +49 (0) 811 8899 6928
  • Ireland: +353 (0) 19 030 053
  • Italy: +39 0 693 38 75 53
  • Netherlands: +31 (0) 208 080 212
  • New Zealand: +64 (0) 4 974 7243
  • Norway: +47 21 04 29 76
  • Spain: +34 931 81 6713
  • Sweden: +46 (0) 852 500 182
  • Switzerland: +41 (0) 225 3311 20
  • United Kingdom: +44 20 3657 6777

Access Code: 619-028-605 Audio PIN: Shown after joining the meeting

Meeting ID: 619-028-605

Participants

2014-10-02 (9:30 am CEST)

Andrés Iglesias Kasper Markus Javi Hernández Kostas Kalogirou


Agenda

http://piratepad.net/ftDniui9o6


  • CAS-FM integration
  • device-platform-application ontology
  • Contexts to support for the review meeting
  • Formats of the contexts
  • Environment reporter/CAS communication with flow manager
  • Overview of remaining tasks
  • Distribution of tasks / integration plan


Minutes

(best seen as source)

  • CAS-FM integration
    • Guillem's not here :-(
  • Kostas' device-platform-application ontology
    • extended from WP204

Ko: are we going to have the same approach as wp204? use a diff tool? A: same approach, same tool, we won't be able to code directly in the RBMM, instead of that we will send 'paper' rules based on our own ontology and they asked us to share the knowledge not the code. they will code in the final step.

  • Contexts to support for the review meeting

Ka: arch meeting and (pcp or pmt?) were consulted Ka: Latest PMT wireframes relating to context: http://wiki.fluidproject.org/download/attachments/34570511/PMT-contexts-sets.pdf?version=1&modificationDate=1412098541345&api=v2 they want easiest context, easily demonstrable luminance bg noise time <-- device

Ko&Ka: regarding the PMT mockups

  • pmt for luminance etc will be something like i want autoadjustment from luminance (yes/no) and so on - and not sure we will have this done in time for the review
  • Andres: The sensors are not precise enough for it to make sense for a user to specify a specific value anyway.slightly diff values from same type device on same place and time

http://wiki.gpii.net/w/Context/Note_on_the_confidence_interval_for_data_from_sensors => 5 to 7 clusters at most J: very diff values from diff devices)

  • Javi's phone get lux values > 1000, 2000 (ridiculously high)
  • ACTION: Javi to check whether we can check sensor's value range (without by having to "calibrate")

A: coupling or calibrating J: values as percents A+J: Ask for testing an APK

  • ACTION: A to set up a wiki page, and to decide the places to check
  • ACTION: J to deliver an apk

A: for the review, have the ability to change the thresholds in the last minute

  • Formats of the contexts

Y3 scenarios are already setted in stone, so

  • ACTION: A to write 'mockups' what will the ER send under these situationst

also, how the MM teams should send (*thinking*) http://wiki.gpii.net/w/Proposal_for_Declarative_Preference_Conditions/Proposal_for_Priority https://code.stypi.com/kaspermarkus/MM%20stuff/MM%20Output.js

need to define the same name (inRange, forRange, range...)

  • ACTION: Ka to decide

http://wiki.gpii.net/w/Proposal_for_Declarative_Preference_Conditions_Datatypes

what component should tell what time it is? the ER checks sensors every 2 secs, so what's the point to inspect the time every 2 secs? it's 2sec more that last time you asked!

A: for android, timers should work, other platforms i don't know J : cross platform solution is preferable Ka: agrees

  • Environment reporter/CAS communication with flow manager

ER more accurate data (really close to screen and speakers of the UI) CAS imprecise data (room-wise, not device-wise)

the cambridge decision was to send ALL OF THE CONTEXTS at once A: sees a combinatory explosion problem here. imagine a pc at library with 3 vers of jaws + nvda+ maavis + readwrite + ... and a user with 5 contexts

Y3R is going to be that way. period


prioritisize the MM mockup !!! examples of the output of the ER output of the MM instead of sending to the sett handler , send that to the lifecycle mgr the word document CONTEXT-usecase-uml-JSON.docx is still good in its "actions" part

go through the flow from one end to the other end /take as well into consideration the PCP

remember card: if the user readjust a value for a preference after being it changed by context, fix the value to the user statement (don't let the context change again the value in the next beat)

Ka: Lot of loose-ends - We should sit down and discuss all together (Andres, Kasper, Claudia, Javi ...)

Ka: better good specs and arch team will code in a rush than crappy spec-less code that doesn't communicate to each other components.

  • ACTION: set up a 'virtual' f2f meeting to discuss this (3 days every afternoon)
  • Overview of remaining tasks

offline

  • ACTION Ka signup trello


  • Distribution of tasks / integration plan