Misc future tasks

Nobody has claimed this yet.

# Integration with existing cloud infrastructure

- [ ] Cloud upload feature - add '&cloud=true' option
- [ ] This would attempt to upload the final result, and then respond with
a 301 perm redirect instead
- [ ] This produces a special `_cloud_link` format file, that contains the
URL to the cloud provider (which is sent back as a perm redirect)

# Render system

- [ ] /render/ Service - A service that takes in ByteResources and outputs
other things.
- Example: `/render/osm-geo:79.1239,32.231345,12/thumb.png:200x300/` --- This
would render Open Street Map into an image, and then use the PNG -> Thumb
converter to resize to the right size
- Example: `/render/text3d:"Hello World!"/webm:200x300/` --- This would
generate Hello World text as 3D shape (obj file), then use the OBJ ->
WEBM to make a rotating image

## Bundling service
- NOTE: Even with the manifest.json media type, this still be useful,
for more convenient manifest format...?
- [ ] zip, tar.gz, tar.bz2, 7z - all bundle formats
- [ ] A more convenient manifest format that allows conversion, maybe a bundle
service to go along with it: /bundle/ Service - A service that takes in an
URL to a json manifest file, which contains an array of files and conversion
destinations to be processed.
- Example: [
{
"url": "http://host.com/file.png",
"path": "media/image/file.png",
"type": "JPG"
},
...
]

## CI + Code badges
- "CI as a microservice"
- Code badge generation - allow another service that is 'ci', which can be
given a (whitelisted) git repo. It then downloads that git repo and attempts
to run something (e.g. with docker). Any remaining artifacts then enter the
"media conversion graph".
- Artifacts could include code coverage graphs, badges, etc
- They could also include built websites, then conversion graph could include
launch
- Just in time deploy: Have serving HTML (e.g. not data) actually trigger build
of entire (e.g. static) site from a repo (HTML served before ready just shows
spinner and refreshes page when ready)
- Thus, omnic becomes "just in time deployment"
- Obvs in real life, this would be triggered with a hook

## Packaging build server Converters
- [ ] Convert "tar.gz" -> rpm, deb, appimage, flatpak etc
- [ ] Convert "python-project.git" -> rpm, deb, appimage, flatpak etc
- [ ] Convert "electron-project.git" -> rpm, deb, appimage, flatpak etc

# Mutable resources
- *NOTE: with Download Scheme this complication might not be needed*

- 'mutable' concept - some foreign URLs might be mutable. All media
generated from them should have much more cautious client-side cache headers.
- e.g. Git would be a ForeignMutable that is turned into a TypedResource
once 'Freshened'
- Git implementation would be bare repo
- [ ] `ForeignMutable` - Behaves differently than foreign resource, can be
transformed into a TypedResource after being 'locked'
- [ ] `freshen()` - Mutates cached resource
- [ ] Store a log of all freshen instances in cache, like `history.txt`
- [ ] `get_history()` - Returns an abbreviated list of version-strings,
one of which can be selected, generally `current` and all previous
instances of freshen.
- [ ] `get_locked(LockString)` - Returns a LockedTypedResource
- [ ] `LockedForeignMutable` - for `git` would represent a specific hash, for
non-VCS, would be a timestamp
- `get_resource(view_selector)` - Returns either a LockedResource resource.
- For VCS, you would use PathViewSelector
- For Chat history, you would use TimeRangeViewSelector
- `get_typed_resource(view_selector)` - Possibly later add this, since for
chat history this would be used, since the resulting resource is of known
type
- [ ] `LockedResource` - Source from a ForeignMutable, it would
simply need to be linked from its true location, can be

## Chat stream (and timeseries?) as a mutable data source

Needs more thoughts, but OmniChat would utilize omnic to render HTML
backlogs. It would have ws servers waiting to push to a (postgres?)
database, and trigger reloads for clients as new messages come in. However,
at the core would be a multi-page app (progressive enhancement), meaning
the core would not require JS (JS would just add the sugar of
auto-refresh). This is to make it feel faster, simpler, and more "solid"
than sluggish competitors.

- Possibly useful front-end fw: http://intercoolerjs.org/docs.html

- More OmniChat ideas:
- "channels" are just "pinned" resources - could be any resource, from an
image to a document
- There's a "auto-pin creator" that in reality just stores a URL to be added
- Full URL:
- /media/chatlogs.html/?url=postgres://host.com/ xyz AND date < xyz>

## Low prio

- [ ] Possibly add in web-worker hook system to base viewer (?) so I
can add PDF.js to the demo
- [ ] Build 1 JS package, but detect if in web worker or not, and
execute different code path for each
- [ ] /ws/ Service - Exposes all other services via a websocket RPC-like
interface. Useful for creating more involved progress-bar UIs etc and
pre-caching longer-running processes
- Still would have no trust, simply exposing the public HTTP interface in
another way, for more involved front-end applications
- Example:
- `< "media", {url: "foo.com/bar.pdf", typestring="thumb.png"}`
- `> "downloaded", {url: "foo.com/bar.pdf"}`
- `> "converting", {url: "foo.com/bar.pdf", type="PNG"}`
- `> "converting", {url: "foo.com/bar.pdf", type="thumb.png"}`
- `> "ready", {url: "foo.com/bar.pdf"}`
- `< "bundle", {url: "foo.com/bar.json"}`
- `> "in-progress", {url: "foo.com/bar.json"}`
- `> "downloaded", {url: "foo.com/bar.json"}`
- `> "downloaded", {url: "foo.com/bar.json"}`

## Likely never useful

- [ ] Checked in cached built version of viewer
- [ ] `CACHE_ALIAS = {'viewers.min.js': {'/path/to/checkout/...'}}`
- Pool should probably be configured, and always run with `runserver`
- [ ] Redis-only commands:
- `omnic runworker` -- runs a worker-only process
- `omnic runserverworker` -- runs a process that is both server AND worker
- `omnic runmulti --worker=1 --server=1 --serverworker=2` -- runs X
processes of the given types
- [ ] @localserver context manager (?)
- [ ] Allows "mini local server" that has can make fake queries via
custom routing
- [ ] Something like: await f.client.get('/media/?qs=abc')
- [ ] General merger of client convert code (should actually spin up
workers) + server routes

This issue is an umbrella list of future ideas and names no implementation files, entry points, or tests. Before starting, split one proposal into a focused issue, identify the relevant service or resource model, and define a testable outcome for that single piece of work.

Written by the indexing model from the issue text.