Instructions: start {@link se.rupy.http.Daemon}, implement {@link se.rupy.http.Service} then {@link se.rupy.http.Deploy}.

Rupy is lightweight and fast.
It also consumes very few joules per request.

The hierarchy of the code is as follows:

   Event -+-- Query <-- Input <--- +-----------+
          |                        |           |
          X                        |  Browser  |
          |                        |           |
          +-> Reply --> Output --> +-----------+

Where X marks the potential Comet pause point.

{@link se.rupy.http.Failure}, {@link se.rupy.http.Hash}, {@link se.rupy.http.Session} and {@link se.rupy.http.Worker} should be pretty self explanatory.

For more details on how to configure rupy, see the properties for Daemon.

----

{@link se.rupy.http.Root} is a distributed JSON database, unfortunately; if you can't figure it out from playing around with these forms then you are out of luck for now!

The only thing I can say simply is each node has a key (private) that allows you to write the node and an id (public) that allows you to read it.

{@link se.rupy.http.User} is a privileged node, because you don't want that to be readable without some kind of authentication; we use double round-trip server salt password hashing over plain HTTP, simple yet secure after registration as long as the connection between the backend and database is trusted because we send the permanent key back over that connection unencrypted.

Other than that, link is one-to-many and meta is many-to-many-to-tree (basically replacing cross reference tables and enabling tree structures in one go).

One use for meta is the inventory system in fuse: see drop, pick, save, load.