Condition-Layout Meeting on 2012-10-17 14:00 UTC

From wiki.gpii
Jump to: navigation, search

Agenda

Telephone Bridge

1. To talk free using the Web click: https://www3.gotomeeting.com/join/705233502 Be sure to set AUDIO to Mic and Speaker (VoIP) - a headset is recommended.

2. Or, call in using your telephone.

Meeting ID/Access code: 705-233-502

  • Australia: +61 (0) 7 3123 6029
  • Austria: +43 (0) 7 2088 1400
  • Belgium: +32 (0) 92 98 0592
  • Canada: +1 (416) 900-1165
  • Denmark: +45 (0) 69 91 88 62
  • Finland: +358 (0) 942 41 5778
  • France: +33 (0) 182 880 456
  • Germany: +49 (0) 898 7806 6461
  • Ireland: +353 (0) 14 845 976
  • Italy: +39 0 247 92 12 39
  • Netherlands: +31 (0) 208 080 379
  • New Zealand: +64 (0) 4 974 7215
  • Norway: +47 21 03 58 96
  • Spain: +34 911 82 9782
  • Sweden: +46 (0) 313 613 558
  • Switzerland: +41 (0) 225 3314 51
  • United Kingdom: +44 (0) 203 535 0621
  • United States: +1 (786) 358-5410

Important Information for the Meeting

This is a meeting of WP204 (Matchmaker) 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 the development of the matchmaker. 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.

Participants

  • Andy (HdM)
  • Kasper (RtF-I)
  • Kostas, Nikos (CERTH)
  • Andres (Tech)
  • Colin
  • Vassilis

Roadmap

Initial proposal: Proposal for Declarative Preference Conditions.

Everybody is fine with the general proposal of using an "Abstract Syntax Tree like" declarative structure (in JSON).

Proposal Questions

How to deal with "named arguments" for the "operators"

How much "intelligence" should be in the parser (preprocessor to resolve things like named arguments, "and-arrays", ...)

Format Requirements

Weak or strong Client?

  • What should be processed on the client and what should be processed on the servers
    • Computational cheap to evaluate, especially if we should have processing on the client
    • Andrez' Mini Matchmaker as a small application to just evaluate conditions in returned profiles from the "Big" Matchmaker

Notes: THINGY on the local device that collaborates with a full matchmaker to quickly respond to context changes (such as ambient brightness, noise, etc.)"

Agreed:

  • There can be conditions which are resolved on the client device via some kind of "mini matchmaker" (or "condition evaluator"), a component which resolves conditions using available context without causing external calls to the c4a architecture
  • The matchmaker on the c4a servers can return preferences to the client which are still affected by conditions

Condition and Context Format

  • Should the condition and context format be the same?
    • Context is more like a statement how the world currently is
      • Probably only "equals" operators
    • Conditions can be more complex

Agreed:

  • Conditions are stored in the user preference set
  • Context is supplied by a client device and the Cloud4all context server
  • Context and conditions don't have to share the same format, but context should be easy to translate into conditions

Optimization

  • Optimize for common cases
    • What are the common cases?
      • Switching between applications
      • Typical environmental changes for mobile devices (light, noise, ...)
      • Time of course

Notes:

  • Context / Condition evaluation on the client does not have to follow the "server-side" specifications. The client application might, for example, index the conditions by sensor

Parser Functionality

Next Meetings and Topics

  • October 24th, 4pm CET

Previous meetings: Matchmaker Meetings

Next Topics