remove scraps

scraps/idea--feed-reader

@@ -1,24 +0,0 @@
-id: 'idea--feed-reader'
-content: |
-  There's no reason for a feed reader to be a single program. Instead,
-  one could build an architecture in which each component is a distinct
-  program that doesn't need to care about the details of the others.
-  For now, I'm going to refer to this system as _lektor_.
-
-  The `lektordir` format is inspired by the `maildir` format for email
-  but modified for feed readers. It similarly includes three
-  subdirectories: `tmp`, `new`, and `cur`. File name generation works
-  similarly.
-
-  However, instead of writing email files, we need a standard way of
-  describing a feed entry. Therefore, instead of writing _files_ to
-  a `lektordir`, update daemons will write _directories_. A given
-  feed entry consists of a directory containing at least four
-  files: `title`, `url`, `id`, and `content`. Other optional files can
-  exist, including `author`, `subtitle`, `summary`, and so forth.
-
-  With this system, adding a new feed type—such as a Twitter feed or
-  an ActivityStream serialization—becomes a simple matter, and an
-  _lektor_ front-end can be created without having to worry about how
-  that data was delivered there in the first place.
-related: []

scraps/idea--http-repl

@@ -1,38 +0,0 @@
-id: 'idea--http-repl'
-content: |
-  It might be overkill, but it also might make sense to implement a rich
-  REPL as a hypermedia API. This would mean that a language could expose
-  an interactive server on HTTP somewhere.
-
-  You could start by requesting the root, which will give you various
-  options for how to proceed.
-
-      GET / HTTP/1.1
-      HOST: localhost:9999
-      Accept: application/ld+json
-
-  You will then get back a JSON object that describes the current state
-  of the interpreter and (more importantly) set of links that describe
-  how to proceed.
-
-      HTTP/1.1 200 OK
-      Content-Type: application/ld+json
-      Content-Length: ....
-      Link: </>; rel=index
-
-      { "@context": "http://api.example.com/repl"
-      , "history" : []
-      , "bindings": []
-      , "operation":
-        [ { "@type": "CreateResourceOperation"
-          , "title": "Evalute an expression"
-          , "method": "POST"
-          , "expects": "http://api.example.com/expression"
-          , "returns": "http://api.example.com/value"
-          }
-        ]
-      }
-
-  This gives us a set of options. We can then `POST` a new command to
-  interpret.
-related: []

scraps/idea--persistent-chat-client

@@ -1,26 +0,0 @@
-id: 'idea--persistent-chat-client'
-content: |
-  One could (to easily work with existing chat services) write a
-  secondary, personal server. This would act as a meta-client,
-  actually being responsible for talking to other chat services,
-  keeping secondary logs of that content and maybe scraping it
-  for image links &c.
-
-  It would then open a (protected) connection to some other kind
-  of chat client, either over an existing chat protocol or using a
-  new secured protocol. If no connections are currently active, then
-  it would set the relevant presence to 'offline', whereas if one
-  or more clients are connected, it will transparently allow any
-  or all of them to communicate.
-
-  (This is in sharp contrast to typical Jabber implementations,
-  which always designate a particular connection as 'active'.)
-
-  It could also send the last dozen (or so) messages send and
-  received to the client, so that switching client in
-  mid-conversation will still keep the user in the loop.
-
-  (Needs a name: ĝi eble povas esti nomita en esperanto?)
-related:
-  - name: idea--persistent-chat-client-diagram
-    why: a more visual explanation

scraps/idea--persistent-chat-client-diagram

@@ -1,24 +0,0 @@
-id: 'idea--persistent-chat-client-diagram'
-content: |
-  Diagrammatically:
-
-      +--------+  +-------+    +-----+  -+
-      | jabber |  | gchat |    | irc |   | remote chat
-      +--------+  +-------+    +-----+   | servers
-           |          |           |     -+
-           +---------+++----------+
-                     |||                -+
-                 +----------+            | remote but
-                 | [server] |            | personal
-                 +----------+            | server
-                      |                 -+
-                      |
-                      |                 -+
-                 +----------+            | local
-                 |  client  |            | client
-                 +----------+           -+
-
-  ...ish, anyway.
-related:
-  - name: idea--persistent-chat-client
-    why: the basic idea

scraps/idea--thule

@@ -1,20 +0,0 @@
-id: 'idea--thule'
-content: |
-  The terminal is old and crappy: this is not a thing that needs to
-  be elaborated on. However, most of the 'modern alternatives', in
-  trying to improve on the terminal, improve away most of the advantages
-  of a terminal.
-
-  Thule (formerly `GBU`) is a hypothetical UI system that stands
-  somewhere between a terminal and window manager, but one that attempts
-  to sidestep many of the problems with other computer UI systems. In
-  particular, it builds on top of a relatively simple UNIX substrate,
-  without trying to reinvent _too_ much elsewhere.
-
-  It consists of a protocol more than an implementation, so that it is
-  easy to reimplement elsewhere in many forms.
-related:
-  - name: idea--thule-architecture
-    why: The basic architecture
-  - name: idea--thule-alternatives
-    why: Problems with similar systems

scraps/idea--thule-alternatives

@@ -1,42 +0,0 @@
-id: 'idea--thule-alternatives'
-content: |
-  The big alternative I know of is
-  [TermKit](https://github.com/unconed/TermKit), which is an interesting
-  experiment: but, to me, it's filled with far too many special cases
-  and not enough nice primitives. For example, there's a special
-  way of outputting a list of files (e.g. output from `ls`) but this
-  isn't because "files" are necessarily a distinct thing, but because
-  there's a special type of output for `ls`-like commands (in this
-  case, `application/json; schema=termkit.files`, which corresponds
-  to a list of filenames.)
-
-  Thule builds on top of this by having a standard set of building
-  blocks, so that you no longer have the special-case "list of files",
-  but rather primitive building blocks like `list` and `file`.
-  Consider the output from `wc`: this also contains file references,
-  but it additionally contains a table mapping those to values. In
-  a TermKit-like setting, you'd have to come up with a new schema
-  (say, `application/json; schema=termkit.wordcount`) that understands
-  which parts of the output are files and which aren't. This is
-  particularly tricky for `wc`, because you want to have the
-  final `total` row, which does _not_ contain a file. And what if
-  other tools also print table-like structures? Can those be
-  processed with the same tools?
-
-  Thule aims to pull those low-level building blocks out, so the
-  output from `ls` might give you a collection like
-
-      (set (file "/tmp/foo.txt") (file "/tmp/bar.c"))
-
-  and the output from `wc` will give you
-
-      (table ((text "lines") (text "words") (text "characters") (text "file"))
-        ((int 10) (int 30) (int 300)  (file "/tmp/foo.txt"))
-        ((int 20) (int 60) (int 900)  (file "/tmp/bar.c"))
-        ((int 30) (int 90) (int 1200) (text "total")))
-
-  rather the structure of the collections would be a hint to the
-  shell on how to display them in a rich way.
-related:
-  - name: idea--thule
-    why: The high-level idea

scraps/idea--thule-architecture

@@ -1,5 +0,0 @@
-id: 'idea--thule-architecture'
-content: tbd
-related:
-  - name: idea--thule
-    why: The high-level idea