Re: Use cases and Blueprints


We (TSC) are putting together a draft with all the terminologies this community to use and a process around it. As we promised in the yesterday’s community call, we will review the draft on next Thursday 11 ET @ community call. The intent is to baseline the version by this month end with TSC approval.

I encourage everyone in the community to join next community call to participate in the discussion.




From: <main@...> on behalf of Glenn Seiler <Glenn.seiler@...>
Date: Friday, September 14, 2018 at 11:41 AM
To: Margaret Chiosi <margaret.chiosi1@...>, "main@..." <main@...>
Subject: Re: [Akraino Main] Use cases and Blueprints


I may have missed some threads, but I thought we were discussing

  1. Integration Blueprints (architecture)
  2. Functional Blueprints  (components)


I agree with some of the other comments that we risk spreading or diluting the definition of Blueprint to broadly and it can be very confusing.

I support the idea that blueprints are pretty specific, not just defining components that are integrated, but how they are intended to be used and deployed.

I’m not sure this would apply to an individual component (or functional) blueprint.




From: main@... [mailto:main@...] On Behalf Of Margaret Chiosi
Sent: Thursday, September 13, 2018 8:22 AM
To: main@...
Subject: Re: [Akraino Main] Use cases and Blueprints


I thought in email folks were ok with the following types of blueprint:
1. Architecture
2. components (Physical/virtual) supporting a specific 'use case'
3. Test

Join to automatically receive all group messages.