|
|
|---|
|
|
|
|---|
Translations database for the VL Server.
At a first approximation, the translation database acts like an alist mapping vl-zipinfos to vls-data-p contents. However, the true story is somewhat more complex due to the desire to keep zips loaded in a more persistent way.
VLS must be fast enough to respond to the web server in real time. Even using serialize-read with ordinary conses, loading a single zip can take over a minute to load, so it is completely infeasible to imagine loading zips on a per-connection basis. Instead, we need some way to keep zips pre-loaded.
This is a challenge due to the number and size of our zips. There many be many new zips from different projects coming into the data directory every day. After a short time there may be hundreds of zips to choose from.
We think it would take too long (and perhaps too much memory) to load everything at once. Instead, we will try to load zips only as the need arises. This might sometimes impose a 1-2 minute wait on a user who wants to get started with a zip that isn't already loaded. But by showing users what zips are already loaded, this penalty can easily be avoided by users who don't need a bleeding edge zip.