Clarify philosophy surrounding Tangelo's typical use cases

[waxlamp]

i.e., rather than a general-purpose, multiuser web server, Tangelo is more like an "application driver" meant for serving one application per invocation, etc. Include some concrete examples if possible.

[waxlamp]

Include note that enabling home directories enables untrusted code to run.

[jeffbaumes]

+1

[waxlamp]

@jeffbaumes what are your thoughts on actually removing the home directory feature altogether? It's another feature that can be emulated by an eager sysadmin, simply by serving Tangelo from somewhere and then creating user-writable subdirectories there as needed.

Removing the feature altogether has these benefits:

1. Simplifies code/logic
2. Makes "security solution" (as discussed in #459) explicit and absolute

The only drawback I can think of is that it will take (a small amount of) time to implement it.

[jeffbaumes]

+2 for both of your reasons.

[waxlamp]

Sitar is turning out to be a great concrete example of this philosophy. Maybe we can mention it in the docs after it's mature enough.

In particular, Sitar now includes a small driver script that embodies the idea of Tangelo as application driver. It may even be possible to generalize that script into a Tangelo utility that generates it, given a few pieces of information about the application.

[jeffbaumes]

Nice. Since I have Docker on the mind, it would be nice to consider how Dockerfiles could expose an application container also.

[waxlamp]

:+1:

[waxlamp]

So here's a list of "featured applications" we could show in the documentation:

• [ ] Sitar, featuring its launcher script
• [ ] A REST service with some widely general usefulness, packaged in a Docker container
• [ ] A wifi manager, as a demonstration of engaging with the OS via Python, with a web front end (this is something I would do on my own time)

I think with the discussion surrounding these in the documentation, along with working on #447, this would be enough to satisfy this issue