@@ -0,0 +1,45 @@
1++++
2+title = "Eyre Request Scry Cache"
3+date = "2022-05-18"
4+
5+[taxonomies]
6+grant_type = [ "Proposal" ]
7+grant_category = [ "Core Dev" ]
8+
9+[extra]
10+image = ""
11+description = "Speed up Urbit http server by implementing a scry mechanism and cache for requests"
12+reward = "10 stars"
13+assignee = ""
14+completed = false
15+canceled = false
16+link = ""
17++++
18+
19+## Rationale
20+
21+Urbit is a personal server, but the webserving part of it is slow, which is a problem for any use case that involves using your urbit as a regular webpage server and handling requests at scale.
22+
23+However, it doesn't need to be slow. For its HTTP I/O driver, Urbit uses a library called H2O, which is incredibly fast, but unfortunately, Urbit cannot take advantage of that speed because every HTTP request currently is routed through the slow Arvo event loop.
24+
25+Since a large amount of HTTP requests are essentially just read requests, we can treat many of them as cacheable scries, which would allow the Urbit runtime to fulfill them without invoking the Arvo event loop.
26+
27+## Implementation
28+
29+### Vere
30+
31+The machinery to peek arvo will need to be set up for use with Eyre, and a cache
32+will need to be configured for H2O.
33+The cache will be filled by polling a scry path in eyre that maps urls to clay paths,
34+then scrying each file in that map out of clay. This allows us to have a
35+two-layered naming system, where nice human-made, mutable, and non-referentially
36+transparent URL paths map to strict referentially transparent clay paths.
37+
38+Inbound GET requests should first try the cache, and if that fails, just invoke
39+eyre in the usual way. Cache misses should add negligible time to HTTP requests,
40+and cache hits will be extremely fast.
41+
42+### Eyre
43+
44+Eyre will store a map from URLs to clay paths, and expose that map at a scry path.
45+New %tasks will be created for eyre to add and remove from this map