Meeting agenda for the 5th of February 2016

[wrygiel]

Issues to be discussed during the Skype meeting on February 5th.

• [x] Officially approve the specifications with the "pending approval" label.

  Once specifications are accepted, we will fight any backward-incompatible change proposals. (Some partners already gave their approval via the mailing list.)

• [x] Michał Kurzydłowski (@Awerin) will start with his implementation soon. He wants to discuss the structure of his application/library. Other developers MAY use his work in their own implementations - if they want to do so, they SHOULD participate.
• [x] We need to reach a final verdict regaring the XML vs. JSON issue (please discuss in issue #2). This will influence the future specifications. If you are a strong supporter of any of these formats, you SHOULD participate.
• [x] Remind everyone to send us their GitHub usernames if they haven't done that already :)
• [x] Discuss plans for February. E.g. we plan to release some automated testing tools and validators. When will other partners need them? When do other partners plan to start their implementations? Etc.

[mikesteez]

I suggest that we leave an opening in the first statement for future changes in the specification. E.g "Once specifications are accepted, all developers MUST write their implementations based on these specifications. The specifications are valid, until a new version replaces the current".

[wrygiel]

Of course, new versions of the specifications may appear and replace the old ones. No version is "final", but we will try to be backward-compatible from that point on :)

[wrygiel]

Changed the description to "Once specifications are accepted, we will fight any backward-incompatible change proposals".

[georgschermann]

i had to review the last recent issues and missed this one completely so to add up to the meeting: we are currently planning to implement the echo and discovery api as soon as the related tools/libs are available and host them on some of our servers with different amounts of HEIs represented (our SAAS server with about 20 HEIs (not all right in the beginning), staging server with about 5 HEIs and a few inhouse servers representing 1 HEI each ) these can also be used for testing, later on we can host dem on most of our servers which would result in ~20 nodes representing around 100 HEIs which should be a good starting point for testing we will start preparing the manifests right away, just inform us when the tools/libs are mostly ready and we will set them up