JK: Reinhard wanted to provide more detail without stating the solution. Look at different challenges separately and then put them together and look for overlaps.
LM: If we want to get into more details - number #10 issue is a good summary. I answered in issue #10 but will things happen in parallel in the same issue or do we create separate issues?
JK: If we break up things need to links them back - can’t do it hierarchically in GitHub unfortunately
LM: Can put the links in the description.
LM: Understood that ‘environment’ was already a type. What made you change?
JK: ‘environment’ was a pname very specific to the device section
LM: If we want a file to be renamed to a new name … just looking for ideas. Wonder if an extended list of attributes would be enough or wanted to attach specific information to a file. Understand why you want to avoid wider use of extensions. We want to be able to create packs that would meet the standard against a hard deadline to include our features.
JK: Have a section where you can do whatever you want and make sure the standard is not affected.
LM: Hard to tell as don’t have a concrete case today.
RK: Have you considered the proposal from NXP to extend the #include filetypes (distinguish C and C++)?The complexity is to keep the compatibility.
JK: Not in this draft.
RK: Main thing is to make sure that we’ve captured all the gaps.
cpackget - contributors/collaborators wanted
LM: looks like a good topic to start collaboration
DJ: Separation of component identification from classification. Would it be possible to make a backward compatible change? My feeling is it seems to be quite counterintuitive (example of Cclass representing two different levels of abstraction - interfaces vs middleware). Is it better to create two different classifications.
Other frameworks are defining their own APIs. If we want to create a successful software manager should support alternative API sets. For example might want to integrate Zephyr in a pack
JK: Could do it under e.g. Cclass Zephyr.
DJ: Could be ‘framework’ and ‘class’ on a lower level.
JK: Sounds like an interesting idea to talk about
RK: RTOS is not standardised - but “CMSIS RTOS” is standardised. FreeRTOS and Micrium are different APIs but can’t use both in an application.
JK: Maybe “middleware class” and “API class” would be more descriptive?
RK: Have both native FreeRTOS API or CMSIS FreeRTOS API in our pack.
JK: CMSIS is a class and RTOS is a class but they seem to have a different scope for meaning.
RK: User could have own naming conventions but what would the user benefit?
MD: Believe it’s disturbing that the same information is expected to be found at different places depending on the components (cf USB). Descriptor should be consistent.
RK: So suggest to add a keyword list?
MD: Yes - dissociate the ID from the classification - but appreciate this is breaking things
RK: Think we need a clear description of the problem we want to solve and a proposal. Don’t understand there’s a problem to call USB drivers vs the USB middleware implementation.
LM: The middleware is only implicit. It isn’t stated anywhere.
RK: Should we work on the taxonomy?
LM: Should be stated in the standard.
RK: think we need an alternative way to identify components or a keywords list. Should we go from the user interface
DJ: Believe it’s more natural to start with the data. The user interface is also being defined in the command line tool but some things are issues in the runtime environment.