aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/docs/love.txt
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--docs/love.txt184
1 files changed, 184 insertions, 0 deletions
diff --git a/docs/love.txt b/docs/love.txt
index c704aba..5e9a981 100644
--- a/docs/love.txt
+++ b/docs/love.txt
@@ -65,3 +65,187 @@ pump in the love server. Lspace just needs read access, and just
65serves the current state of the world. Love server persists to disk 65serves the current state of the world. Love server persists to disk
66when it's ready to, though the shared memory can just be memory mapped 66when it's ready to, though the shared memory can just be memory mapped
67files. 67files.
68
69
70Thoughts about directory structure.
71========================================
72
73A major goal is to have the disk structure of a sim (and inventory) be
74decently human readable. The assets should be stored as normal files of
75the appropriate type, so that they can be edited with normal editing
76software like blender, gimp, a text editor, etc. Oter goals include not
77duplicating assets, and making it easy to move assets around.
78
79Names.
80------
81
82A major LL created problem is that in world objects can have the same
83name, though stuff in an objects inventory is forced to have unique
84names by automatically adding numbers to the names. In inventory you
85can have stuff with the same name to. The same named objects don't have
86to be the same object, they can be completely different. A simple
87object name to file name matching, with directories for contents, just
88wont work. Need to munge the names anyway.
89
90All name munging should produce names that are compatible with various
91OS file systems, compatible with URLs, add "_123" numbers at the end for
92duplicate names in the same directory, and auto add a file extension if
93one is missing. Probably should check the file type if there IS a file
94extension.
95
96Links and URLs.
97---------------
98
99Any asset file could be a stuffs.lnk file, which holds a relative path
100name or full URL pointing to the real asset. An external lspace server
101would return the .omg file when the stuffs URL is requested, or an
102actual asset file when those are requested.
103
104Would have to do copy on write for editing and other state changes, not
105including script state changes.
106
107Probably need to store other info in the .lnk file if it's a URL, SHA-1
108of the original file, other web cache info. Which starts to encroach on
109web proxy / cache territory, which we may not want to do, since we want
110to use real ones instead of crappy LL cache.
111
112Actually, file names / URLs in .omg files would mostly be relative to
113the file name / URL of the sim, and all the way down, so relative to the
114directory things are in. It's up to the client to keep track of where
115they are and build appropriate full URL / full path file names.
116
117UUIDS.
118------
119
120Original LL UUIDs are the usual 36 byte string representing 32 lower
121case hex characters and some dashes, encoding a 128 bit number. I was
122inspired by git using SHA-1 hashes for content addressable assets.
123SHA-1 hashes are 40 character hex codes representing 160 bit numbers
124that are calculated based on the content. So the same content will give
125the same SHA-1 hash. Git has proved that you only need the first digits
126of the SHA-1 hash to ensure uniqueness, so it's feasable to use only the
127first 128 bits of SHA-1 hashes to squeeze it into a UUID for the
128purposes of uniquely identifying assets. Precisely what git does. This
129means it could be backwards compatible with LL's use of UUIDs.
130
131Since the SHA-1 code of identical files is the same, we could use this
132to reduce duplicated large assets that never change, like textures and
133sounds. This will be a big win.
134
135I think we can get away with not storing SHA-1 hashes permanently, just
136use them for in memory references, but cache them to disk separately.
137The caches can be recreated at any time, since the SHA-1 hashes can be
138calculated based on the data in the assets. So no UUIDs stored in .omg
139files, just relative file / URL friendly names. The UUID / SHA-1 hashes
140are mostly for keeping in memory as keys to stuff, coz they can shrink
141down to a long long 128 bit integer.
142
143Each asset file, whether texture, script, mesh, text file, etc, comes
144with a matching .sha1 file that holds the SHA-1 hash of that file. .lnk
145files get hashed to, so that each copy of a linked stuffs gets it's own
146SHA-1 hash, but in this case the "content" is the relative path name.
147The .sha1 files of the real asset .lnk files point to can be found in
148the same place the real asset file is.
149
150There will be a .sha1 directory full of files with the SHA-1 hashes as
151part of the name, and the rest being similar to a .lnk file, a path to
152the asset or .lnk file. Would save love server needing to keep that all
153in memory all the time.
154
155If the file system date stamp for the asset file is later than the one
156for the .sha1 file, then someone edited the file, recreate the .sha1
157files.
158
159All the SHA-1 hashes can be recreated at any time, using file system
160date stamps to tell if one is stale. They are only used internally to a
161running system, to pass small identifiers around, and to fake LL UUIDs
162for LSL scripts. When a SHA-1 hash is calculated for a new asset, it
163gets stored in the .sha1, but if it already exists in .sha1, then the
164asset is replaced by that sha1.lnk file, thus automatically
165deduplicating assets.
166
167On disk structure.
168------------------
169
170"some sim name" -> some%20sim%20name/index.omg
171 list of stuffs rezzed in the sim
172 stuffs position, orientation, and size
173 relative file / URL name pointing to the stuffs
174 no need for the in world name, those interested in that will likely grab the stuffs.omg file anyway
175
176 "a stuffs" -> a%20stuffs.omg
177 in world name, description
178 list of stuffs similar to the sim index.omg, only this is for the various meshes that make up this stuffs.
179 stuffs position, orientation, and size
180 relative file / URL name pointing to the mesh and textures
181 extra info for each material
182
183 a%20stuffs/ directory
184 files that are the contents of this stuffs
185 could be .lnk files
186 .sha1 files
187
188 a%20stuffs/index.omg
189 used to be a list of content file names, type, and UUID
190 file names are right there in the directory
191 UUID ala SHA-1 can now be calculated based on those files
192 and stored in a asset.sha1 file
193 type can use the magic/file/MIME system to identify file types
194 can get rid of this file, though maybe have it in a .types directory,
195 coz we would want to cache the file type
196 or just use a poor mans magic/file/MIME thingy based on file extension,
197 since we only have a small number of file types
198 note cards should have a .txt, scripts a .lsl or .lua
199
200People could even be free to use their own organising directory
201structure. A directory for ground level, and one for each sky box for
202instance. Relative paths inside .omg files sorts that all out.
203
204A sims index.omg file might be constantly updated for busy sims. Could
205generate it on the fly by the lspace server, based on the actual
206contents of the sim directory. Alternative lspace servers could just
207use a CMS system for all of this anyway. They would still use the same
208structure for URLs and .omg files.
209
210Avatars.
211--------
212
213Storing avatars in this way isn't such a good idea? Avatars could have
214their own avatar.omg dealing with shape, skin, clothes, attachments,
215etc. But instead of a client asking for a list, avatar arrivals and
216departures are driven by love. Though try to keep avatars as "just
217ordinary object, but with a person controlling it". Still, they move
218around a lot.
219
220Avatar.omg would live on the users hard drive, but sent to the love
221server on login, and after any change.
222
223Misc.
224-----
225
226Right now I'm using Lua style .omg files, but eet would be a better
227choice I think. Saves having to write a Lua table to C structure
228system, which eet already has, sorta. Lua tables are at least more
229readable while I consider the design, but likely use eet instead when I
230have to write code to read the suckers. .omg files are managed by the
231love server, so fiddling with them is an expert thing anyway.
232
233Should have a tool to validate a sims files and recreate te caches.
234
235Remaining issues.
236-----------------
237
238Owner / group UUID might be better dealt with elsewhere? Coz links.
239Also, we wont replicate the LL user / group stuff exactly, but morph
240into more standardised variations. Jabber users, jabber group rosters,
241OS users, web site users, etc. So just provide an abstraction, and an
242example or two.
243
244The asset files, plus things like compiled script binaries and temporaries
245 might be better to move compiled scripts and generated Lua source to the LuaSL server's own private store?
246 LuaSL needs to assign UUIDs to compiled script binaries, so it knows which running script is which
247 coz there might be lots of copies of scripts
248 on the other hand, each copy is uniquely named inside some objects contents,
249 even if it's a link,
250 so the UUID of the stuffs plus the UUID within the stuffs contents, for this copy / link of the script should suffice?
251