Draft Meeting minutes for July 2nd

[Nick Crossley <ncrossley@us.ibm.com>]

Sorry - previous mail should have said meeting minutes for June 18th!

Here are the draft meeting minutes for our previous meeting, on July 2nd. We will review these minutes during tomorrow's meeting.

Chat transcript from room: oslc-ccm 2015-07-02 GMT-08:00

[07:05] Jim Amsden (IBM): Scribe: Jim Amsden

[07:05] List of attendees: Brian Steele (IBM), David Honey (IBM), Jim Amsden (IBM), Martin Sarabura (PTC), Nick Crossley (IBM), Rainer Romatka (Boeing)

[07:06] Nick Crossley (IBM): Previous meeting minutes: https://wiki.oasis-open.org/oslc-ccm/Meetings/Telecon2015.06.18

[07:06] Jim Amsden (IBM): Approval of previous minutes: no objections - approved

[07:07] Nick Crossley (IBM): Jim: Change Mgmt - no action taken during last 2 weeks. Jim read the spec and it looks in good shape

[07:08] Jim Amsden (IBM): Core compatibility is an important topic for all domains, Nick revising the spec to rely on v2 discovery compatibility

[07:08] Jim Amsden (IBM): CCM no longer uses actions and does not depend on a query service, but does use LDP

[07:09] Jim Amsden (IBM): CM still needs to deal with Actions, it could use its own Actions, or rethink this and determine a new direction.

[07:11] Jim Amsden (IBM): Whenever a OASIS meeting is rescheduled, Lotus Notes uses the wrong year and moves the repeating invitation

[07:11] Jim Amsden (IBM): This may cause some meetings to appear to be removed from your calendar and so meetings are missed leading to quorum problems

[07:13] Jim Amsden (IBM): Core v2 compatibility is still pending a vote by the Core TC.

[07:13] Jim Amsden (IBM): Leaving Configuration Management vocabularies incomplete. Want to validate that vocabulary and shapes are compatible

[07:14] Jim Amsden (IBM): using tooling to check consistency. Discussed using SQARQL. But decided to write a Java program using Jena to have more flexibility.

[07:15] Jim Amsden (IBM): Reads in a number of vocabularies and shapes, checks for consistency and produces RDF output listing the vocabulary terms and notes any issues found.

[07:16] Jim Amsden (IBM): Could put a Web based front end on this, but not done yet.

[07:16] Jim Amsden (IBM): Not yet published. Thinking of releasing in an SVN repository, say under Core in a Tools directory.

[07:17] Jim Amsden (IBM): Designed to be applicable to any vocabulary and shape.

[07:18] Jim Amsden (IBM): ReSpec is currently in Steve's GitHub, we can make changes there, but does rely on Steve.

[07:19] Jim Amsden (IBM): Rely on Steve to merge any changes.

[07:20] Jim Amsden (IBM): Nick made a change to sort the properties table to sort by property name.

[07:21] Jim Amsden (IBM): Steve updated the ReadMe to describe how to update, build and test ReSpec

[07:22] Jim Amsden (IBM): Nick no preference between Git and SVN, consideration is that it is accessible to OSLC TCs for future use and adaption to LDP constraints

[07:22] Jim Amsden (IBM): Nick will create a tools director in Core SVN and place the tools there.

[07:23] Jim Amsden (IBM): The ReSpec GitHub should probably be cloned to make it independent of Steve

[07:24] Jim Amsden (IBM): RTC 6.0 GCM shipped last week and that CCM implementation will provide useful feedback

[07:24] Jim Amsden (IBM): Desire to keep CCM 1.0 as simple as possible.

[07:25] Jim Amsden (IBM): The current global configuration protocol relies on global component knowing the complete contribution tree

[07:25] Jim Amsden (IBM): Resolving a reference to a resource requires constriction of this tree. GC provider could cache this for faster access

[07:26] Jim Amsden (IBM): local client cache could be used instead

[07:26] Jim Amsden (IBM): Raises an issue keeping the caches refreshed

[07:27] Jim Amsden (IBM): Multiple global config providers with different hierarchical levels, could result in a lot of data that needs to be cached.

[07:27] Jim Amsden (IBM): Alternative, break into chunks so that each provider that provides hierarchies could be responsible for its own part of the subtree

[07:28] Jim Amsden (IBM): Limits caching to smaller number of layers within the trees, with multiple contributors.

[07:28] Jim Amsden (IBM): Nick to write this up and discuss with David.

[07:28] Jim Amsden (IBM): Will help with scalability, and avoid dependencies that no other OSLC standard introduces - a messaging system

[07:30] Jim Amsden (IBM): Tradeoff between efficiency and currency. If the tree contained multiple layers of cache providers, would lead to some performance cost, but helps maintain currency.

[07:32] Jim Amsden (IBM): If currency can be latent, then client might need to know this somehow in order to decide how to react to potential stale data

[07:33] Jim Amsden (IBM): Client request to get a resource in a configuration, passed in a header or query string - means request goes to the server that owns the data. That server participates in a conversation with the global configuration provider and any other local configurations contributed by other servers - this communication is the source of the performance issues.

[07:35] Jim Amsden (IBM): Etags, and other information can indicate what configuration contributed the resource, but there's nothing returned that indicates anything about the caching of the configuration tree itself. So client cannot know if the configuration cache is stale and implications on the resource version returned.

[07:37] Jim Amsden (IBM): Comment on current spec, extra triples in response for multiple matches in multiple configurations - ReturnRepresentation Link header, might cause the version in a baseline to appear to change depending on context used.

[07:39] Jim Amsden (IBM): Coould use a hash resource referenced in a Link header that could be ignored

[07:39] Jim Amsden (IBM): Otherwise clients could just ignore the extra triples

[07:42] Jim Amsden (IBM): Preserving imutability of a baseline may be important to others. Nick leaning to changing the spec to use the hash approach

[07:44] Jim Amsden (IBM): The same resource could be found in multiple configurations in the global configuration - separate out where the resource was found from the resource data itself.

[07:45] Jim Amsden (IBM): Separate this location/path information into a separate resource accessed through a link header so that the client can use it if needed, or ignore it if not.

[07:46] Jim Amsden (IBM): There isn't a use case that describes how a client would use this information

[07:47] Jim Amsden (IBM): Clients could put a warning to the user that the resource was found in more than one configuration.

[07:48] Jim Amsden (IBM): Perhaps the configuration is poorly configured.

[07:49] Jim Amsden (IBM): Human user would probably understand suggestions about focusing the configuration scope to avoid multiple results

[07:50] Jim Amsden (IBM): Four LDPC involved, per config provider with all components, one per component with all configurations. Could be read-only container. Additional, LDPC of streams per baseline, and LDPC of baselines per stream

[07:53] Jim Amsden (IBM): Conclusion that there is no need to define link headers on these new LDPC that hinted at the timeliness of likely response

[07:53] Jim Amsden (IBM): Clients need to handle request accepted response anyway, so hint wouldn't be that useful.

[07:54] Jim Amsden (IBM): Action for Nick: post code for vocabulary/shapes verification to Core/Tools, and then run these tools on the CCM vocabulary

[07:55] Jim Amsden (IBM): Nick will probably move the stable tag once this verification has been done.

[07:55] Jim Amsden (IBM): It currently reflects what IBM released publicly

[07:55] Jim Amsden (IBM): Will do this before any changes to caching as discussed above.

[07:56] Jim Amsden (IBM): Or other semantic, not reorg changes

[07:56] Jim Amsden (IBM): Use tags or branches to reflect major milestones for implementation or reorganization of the files.

[07:58] Jim Amsden (IBM): No other business

[07:58] Jim Amsden (IBM): Meeting closed.