To this point we have only mentioned the web to talk about context for the development of the cards model, and to note the lack of dependencies on rails outside of the model classes.  A few more dependencies come about in formatters and views that are a bit web-specific and need to use rails route helpers and the like.  In other words, we can completely separate this universal content model (cards) from the applications that might use them.  Any dependence on web support is because the modules are implementing a formatter for a web application.  Maybe in stardard mods, but not core.

We are very close to achieving this separation in code by way of an independant gem for cards, and other gems that make it into a deployable application.  Starting with the card gem and its dependencies, all it takes to make this a rails engine is some routes and a single controller with about 300 lines of code and a few hundred more of config and glue code.  There is a bunch of other stuff to support the application in the form of assets like javascript libraries and images as well as some generator commands that extend rails generators.  There is more work to be done to complete support for common use cases for card based applications.  Now they support generating a particular card based web application called wagn, but we also want to support rails developers who want to add cards to an existing rails application.

In practice, applications, web based and otherwise will be using groups of components packaged in different ways.  Ruby and rails use bundler and gems, and front-end technology is more often based on node and other packaging and dependency management native to javascript.  Now we add card mods to the mix and we need to think and design carefully the best ways to configure card based application.

Whether you are primarily using web protocols, or doing something else, the paradigm of a networked web of applications is well supported by the card model.