[feedhenry-dev] mobile client or mobile app

[David Martin]

The term 'Resource' may not suit as it has a meaning in the Kubernetes
world.
Any object that kubernetes exposes an API for is a resource e.g. Secrets,
Pods, Deployments are all resources.

In UPS, there's the idea of a 'Push Application', defined here [1]
"PushApplication
A logical construct that represents an overall mobile application"

I don't see any problem with giving it a name like 'Mobile Client' and
calling it out in terminology in a similar manner
"MobileClient
A logical construct that represents an overall mobile application"

[1]
https://aerogear.org/docs/unifiedpush/ups_userguide/index/#_useful_terminology

On 29 November 2017 at 09:42, Paul Wright <pwright at redhat.com> wrote:

> and that conversation makes me think we need to be more descriptive, eg
>
> Mobile App Resource Client (MARC)
>
> Paul
>
> On 11/29/2017 09:38 AM, Craig Brookes wrote:
>
> Spoke with Paul offline. And he thought we were referring to mobile app
> through out our docs. So to clarify I meant with the context of the mcp UI
> and CLI.
>
> On Mon, Nov 27, 2017 at 11:49 AM, Paul Wright <pwright at redhat.com> wrote:
>
>> It seems to me that to tackle the mobile market, we should embrace the
>> lingua franca, and the one word that unites mobile,cell phone, smartphone,
>> handys, etc is 'App'
>>
>> Paul
>> my original draft reply:
>>
>> Mondays...
>>
>> Let's fix everything <sigh>
>>
>> I'm not against this change, but would like to throw in a note of caution:
>>
>> 1. I don't think OpenShift are really pushing the term apps. Sure,
>> there's a command, and even some doc references (
>> https://access.redhat.com/documentation/en-us/openshift_ent
>> erprise/3.2/html/installation_and_configuration/install-
>> config-imagestreams-templates#creating-instantapp-templates), but would
>> like to check with them before assuming that's deliberate. In my mind,
>> their term of choice is Application, a bit more of an enterprisey term.
>>
>> 2. Does "Mobile Clients" solve a problem? we already have a generation of
>> ppl saying "there's an app for that", do we want to embrace that or swim
>> upstream? what about when there's a web ui to something, we used to bundle
>> mobile and web into the term 'client app'.
>>
>>
>>
>>
>>
>> On 11/27/2017 11:03 AM, Jason Madigan wrote:
>>
>> Deep thoughts this early in the week. App is quite a loaded term alright,
>> particularly in an OpenShift context, so I think Mobile Client may be a
>> clearer distinction.
>>
>> Looping in our wordsmith Paul who may have other ideas.
>>
>> On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes <cbrookes at redhat.com>
>> wrote:
>>
>>> Was thinking about terminology . We have been using the term mobile app,
>>> but I wonder would it be clearer to use the term mobile client instead.
>>> The main reason for this is that app can mean a server side component
>>> (in OpenShift there is the new-app command for example). I think it would
>>> make a clearer distinction. Another example is around the word build. When
>>> you do an app build in OpenShift it normally produces a docker image and a
>>> running server / app. I think using the the term mobile client build makes
>>> it clearer what is happening.
>>>
>>> Just a thought for a Monday morning.
>>>
>>> --
>>> Craig Brookes
>>> RHMAP
>>> @maleck13 Github
>>>
>>> _______________________________________________
>>> feedhenry-dev mailing list
>>> feedhenry-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>
>>>
>>
>>
>> --
>> Jason Madigan
>> Engineering Manager, Red Hat Mobile
>>
>>
>>
>
>
> --
> Craig Brookes
> RHMAP
> @maleck13 Github
>
>
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>


-- 
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171130/cc96e05b/attachment.htm>