diff options
Diffstat (limited to '')
-rw-r--r-- | docs/love.txt | 67 |
1 files changed, 67 insertions, 0 deletions
diff --git a/docs/love.txt b/docs/love.txt new file mode 100644 index 0000000..c704aba --- /dev/null +++ b/docs/love.txt | |||
@@ -0,0 +1,67 @@ | |||
1 | Love makes the world go around. Though in this case, it's the name of | ||
2 | the world server, the module that directly controls what happens to the | ||
3 | content of the virtual world. | ||
4 | |||
5 | The love world server that deals with changing the world. It manages | ||
6 | the on disk representation of the world, and lets others screw with it | ||
7 | via nails pumps. Love also sends nails events on changes. | ||
8 | |||
9 | World server vs local world. | ||
10 | ---------------------------- | ||
11 | |||
12 | Extantz defaults to running a local world at start up. Lspace serves | ||
13 | the content for a networked world. They may be the same world if the | ||
14 | local world is also networked. Nails pumps commands to and from the | ||
15 | world. | ||
16 | |||
17 | Lspace just serves the results as a web server. The love world server | ||
18 | changes on disk content, Lspace checks on disk modified time stamps to | ||
19 | deal with "do you have a newer version" HTTP requests. Standard web | ||
20 | server stuff really, though a mod_nails might be useful to catch events | ||
21 | in order to invalidate any internal web caches. | ||
22 | |||
23 | For networked worlds, Extantz fetches new content from Lspace, and hooks | ||
24 | up to the nails pump of the love server for changes. For local worlds, | ||
25 | extantz would basically BE the world server? No, that duplicates | ||
26 | things, it can just run a local love server, then connect to it like | ||
27 | every one else. No need to connect to a local Lspace server, just deal | ||
28 | with the file system direct. | ||
29 | |||
30 | The local love server would be configured to listen on 127.0.0.1, and/or | ||
31 | the outside IP address. Extantz checks to see if there's one running on | ||
32 | 127.0.0.1 first before starting one if needed. | ||
33 | |||
34 | Separate vs combined. | ||
35 | --------------------- | ||
36 | |||
37 | There's two ways of doing this. The world server could be part of | ||
38 | Lspace, or they could be separate modules. What we really have is a web | ||
39 | server, backing store, and command pump. The command pump is nails, and | ||
40 | should be a library that is shared, since both ends of the protocol | ||
41 | would be needed by most modules. | ||
42 | |||
43 | Combined might be useful to conserve resources. They both need to deal | ||
44 | with the contents of the world. Lspace just serves it to the outside | ||
45 | world via HTTP, but needs to track changes. Love makes those changes, | ||
46 | and also sends changes via nails to every one. Keeping the current | ||
47 | working set in memory only once saves a lot of memory. | ||
48 | |||
49 | The down sides of combined is that one might bog down the other, and it | ||
50 | gets harder to use standard web servers. | ||
51 | |||
52 | Separated is good coz Lspace might just be any ordinary web server. | ||
53 | They already have mechanisms in place to serve dynamic data, and even | ||
54 | deal with changes to the files. | ||
55 | |||
56 | The down side of separated is that changes might be slower propogating | ||
57 | to the web server, and there might be two copies of any given set of | ||
58 | assets in memory at once. | ||
59 | |||
60 | A third option is to be separated, but any given web server could have a | ||
61 | mod_love type module written for it. This could share memory with the | ||
62 | love server process. So tighter integration is an option, but they can | ||
63 | work apart. Changes happen in this shared memory, driven by the command | ||
64 | pump in the love server. Lspace just needs read access, and just | ||
65 | serves the current state of the world. Love server persists to disk | ||
66 | when it's ready to, though the shared memory can just be memory mapped | ||
67 | files. | ||