merged in Schoons' changes to mobile clients section

docs/concepts.md

@@ -31,34 +31,36 @@ notifications, register users, and any other behavior provided by data sources.
 
 ### Mobile Clients
 
-LoopBack Mobile Client SDKs give mobile developers access to
+LoopBack provides native Client SDKs to give mobile developers access to remote,
-mobile models and services from within their native
+persistent data in a contextually-relevant way. The transport and marshalling of
-development environment and language.
+the data is taken care of, and mobile developers can leverage all of their
+existing tools (XCode, Eclipse, et al) to model their data on the client,
+persisting it to the server as needed.
 
-LoopBack SDK's support both predefined static schema's and dynamic
+To achieve this, LoopBack supports both "Dynamic", schema-less Models and
-'schema-less'mobile models.
+"Static", schema-driven Models. (See ["Models"](#models) for more specifics and
+how-tos around Model creation.)
 
-A Dynamic or Schema-less model strategy allows mobile developer to
+Dynamic Models require minimal server code up front (just a name!) to set-up,
-define custom model definitions directly from the SDK that are often
+with the format of the data specified _completely_ and _flexibly_ by the client
-specific to a mobile application needs.  Similar to 'Document
+application. Well-suited for data that _originates on the client_, mobile
-Storage' solutions such as Redis or MongoDB.  Dynamic models have
+developers can leverage Dynamic Models to persist data both between sessions and
-the added benefit of allowing mobile developers to work with
+between _devices_ while obviating the need for outside engineering support.
-LoopBack as a Mobile back end-as-a-service (mBaaS) without having to
+(Let's be honest - how many server programmers do you know that are _excited_
-predefine the model definition on the server.  This strategy is
+when you ask them to add a field to some schema on the server? None? That's what
-often leveraged for data that originates on the mobile device and
+we thought.)
-then persisted in the Mobile backend for later mobile consumption or
-server side processing.
 
-Static or traditional schema strategies are also supported in
+Static Models require more code up front in an extended grammar of JSON we call
-LoopBack.  A static model configuration promote a consistency in
+LDL, with the format of the data specified _completely_ in a _structured_ way by
-mobile model data and provides easy integration or direct binding to
+the server application. Well-suited to both existing data and large, intricate
-traditional RDBMs such as Oracle and MySQL. The added governance and
+datasets, mobile developers can leverage Static Models to provide structure and
-reliability in providing a 'rigid' model also promotes more robust
+consistency to their data, preventing the multitude of bugs that can result from
-data integrity, validation and standardization.
+unexpected data in their database. (These pesky bugs _love_ to show up in
+production and ruin everyone's launch day. Stop them before they start!)
 
-The ability to leverage either or both strategies in a mobile middle
+Use one strategy, or use both. Leverage them to fit your _use case_, rather than
-tier allows developers to select the best implementation for their
+fitting your use case to some fixed modelling strategy. The choice is yours.
-use case.
+>>>>>>> 315218c79b59a51b5c3e2d93388ffb65d3510525
 
 ### Models
 
@@ -280,7 +282,7 @@ layer that supports surfacing backend APIs over REST, WebSockets,
 and other transports.
 
 <h4> API Gateway </h4>
-The first line of defense and entry is the  API gateway.  This
+The first line of defense and entry is the API gateway.  This
 sub-component of LoopBack acts as a reverse-proxy to the rest of
 LoopBack.  It provides OAuth2 based security, will mediate between
 multiple data formats and acts as a quality of service layer for your