Hi Chris, thanks for starting this discussion, can I object to one item: Security & Identity Management = keycloak because this is likely to end up in downstream documentation, we should avoid names of upstream projects. In this case I hope we can use something like 'identity' instead? Paul On 01/10/2018 11:44 AM, Chris Foley wrote: Hi All, I had a brief discussion with John around Naming Conventions and what may be worth putting in place which could be beneficial but not restrictive. I wanted to kick start discussion on this around what may be worthwhile. An important aspect of 5.x is the value add services and getting these in place and discoverable from Mobile Core. Should we be applying some naming convention or mandatory attributes to these services? Attributes / Properties of a Service, e.g. ; ---------------------------------------------- *Display Name*: Push Notifications *id / serviceName*: push *APB Label/Tag*: mobile-service Would it be any benefit if the APB tag (mobile-service) carried over and became a label on the OCP service (e.g. for the Core SDK to read what Mobile Services are available in a namespace)? *APB Integrations*: <list of service ids of the services this service integrates with> Some of the above may be agreed already! We should agree on the actual serviceNames (interested to hear the Mobile Service Teams view on what the names should be): Metrics = metrics Push Notifications = push Data Synchronisation = sync Security & Identity Management = keycloak Mobile Build Automation = build API Gateway = gateway Are there other naming aspects which could be worthwhile getting agreement on? Around the SDKs, as they are being designed now, it is probably worth considering also. All opinions welcome. Best Regards, Chris. -- CHRISTOPHER FOLEY BUSINESS SYSTEMS ANALYST, MOBILE Red Hat Ireland <https://www.redhat.com/> Communications House, Cork Road, Waterford City, Ireland X91NY33 chfoley(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> _______________________________________________ feedhenry-dev mailing listfeedhenry-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/feedhenry-dev -- Paul Wright Mobile Docs (github: finp) _______________________________________________ feedhenry-dev mailing list feedhenry-dev(a)redhat.com https://www.redhat.com/mailman/listinfo/feedhenry-dev

+1. I prefer `auth` as `security` is too vague. On Thu, Jan 11, 2018 at 2:28 PM, John Frizelle <jfrizell(a)redhat.com&gt; wrote: > Agree that "Security & Identity Management" should not be "keycloak" > > Suggest we use "auth" or "security" instead. > > @Joe - I would hope that we could come up with names that work both > upstream and downstream. Which ones would you have questions/concerns about? > > -- > John Frizelle > Chief Architect, Red Hat Mobile > Consulting Engineer > > mobile: *+353 87 290 1644 <//+353872901644>* > twitter:* @johnfriz* > skype: *john_frizelle* > mail: *jfrizell(a)redhat.com <jfrizell(a)redhat.com&gt;* > > > > > On 11 January 2018 at 09:35, Paul Wright <pwright(a)redhat.com&gt; wrote: > >> Hi Chris, >> >> thanks for starting this discussion, can I object to one item: >> >> Security & Identity Management = keycloak >> >> because this is likely to end up in downstream documentation, we should >> avoid names of upstream projects. In this case I hope we can use something >> like 'identity' instead? >> >> Paul >> >> On 01/10/2018 11:44 AM, Chris Foley wrote: >> >> Hi All, >> >> I had a brief discussion with John around Naming Conventions and what >> may be worth putting in place which could be beneficial but not >> restrictive. I wanted to kick start discussion on this around what may be >> worthwhile. >> >> An important aspect of 5.x is the value add services and getting these >> in place and discoverable from Mobile Core. Should we be applying some >> naming convention or mandatory attributes to these services? >> >> Attributes / Properties of a Service, e.g. ; >> ---------------------------------------------- >> *Display Name*: Push Notifications >> *id / serviceName*: push >> *APB Label/Tag*: mobile-service >> Would it be any benefit if the APB tag (mobile-service) carried over and >> became a label on the OCP service (e.g. for the Core SDK to read what >> Mobile Services are available in a namespace)? >> *APB Integrations*: <list of service ids of the services this service >> integrates with> >> >> Some of the above may be agreed already! >> >> We should agree on the actual serviceNames (interested to hear the >> Mobile Service Teams view on what the names should be): >> Metrics = metrics >> Push Notifications = push >> Data Synchronisation = sync >> Security & Identity Management = keycloak >> Mobile Build Automation = build >> API Gateway = gateway >> >> Are there other naming aspects which could be worthwhile getting >> agreement on? Around the SDKs, as they are being designed now, it is >> probably worth considering also. >> >> All opinions welcome. >> >> Best Regards, >> Chris. >> -- >> >> CHRISTOPHER FOLEY >> >> BUSINESS SYSTEMS ANALYST, MOBILE >> >> Red Hat Ireland <https://www.redhat.com/> >> >> Communications House, Cork Road, >> >> Waterford City, Ireland X91NY33 >> >> chfoley(a)redhat.com >> <https://red.ht/sig> >> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> >> >> >> _______________________________________________ >> feedhenry-dev mailing listfeedhenry-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> >> -- >> Paul Wright >> Mobile Docs (github: finp) >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev(a)redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev(a)redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- WEI LI SENIOR SOFTWARE ENGINEER Red Hat Mobile <https://www.redhat.com/> weil(a)redhat.com M: +353862393272 <https://red.ht/sig> _______________________________________________ feedhenry-dev mailing list feedhenry-dev(a)redhat.com https://www.redhat.com/mailman/listinfo/feedhenry-dev