Love makes the world go around. Though in this case, it's the name of the world server, the module that directly controls what happens to the content of the virtual world. The love world server that deals with changing the world. It manages the on disk representation of the world, and lets others screw with it via nails pumps. Love also sends nails events on changes. World server vs local world. ---------------------------- Extantz defaults to running a local world at start up. Lspace serves the content for a networked world. They may be the same world if the local world is also networked. Nails pumps commands to and from the world. Lspace just serves the results as a web server. The love world server changes on disk content, Lspace checks on disk modified time stamps to deal with "do you have a newer version" HTTP requests. Standard web server stuff really, though a mod_nails might be useful to catch events in order to invalidate any internal web caches. For networked worlds, Extantz fetches new content from Lspace, and hooks up to the nails pump of the love server for changes. For local worlds, extantz would basically BE the world server? No, that duplicates things, it can just run a local love server, then connect to it like every one else. No need to connect to a local Lspace server, just deal with the file system direct. The local love server would be configured to listen on 127.0.0.1, and/or the outside IP address. Extantz checks to see if there's one running on 127.0.0.1 first before starting one if needed. Separate vs combined. --------------------- There's two ways of doing this. The world server could be part of Lspace, or they could be separate modules. What we really have is a web server, backing store, and command pump. The command pump is nails, and should be a library that is shared, since both ends of the protocol would be needed by most modules. Combined might be useful to conserve resources. They both need to deal with the contents of the world. Lspace just serves it to the outside world via HTTP, but needs to track changes. Love makes those changes, and also sends changes via nails to every one. Keeping the current working set in memory only once saves a lot of memory. The down sides of combined is that one might bog down the other, and it gets harder to use standard web servers. Separated is good coz Lspace might just be any ordinary web server. They already have mechanisms in place to serve dynamic data, and even deal with changes to the files. This is the whole point of basing the major asset shifting part of the protocol on the web, people can use all the major amounts of web infrastructure that already exists and already solves most of the problems that currently plague virtual worlds based on SL tech. The down side of separated is that changes might be slower propogating to the web server, and there might be two copies of any given set of assets in memory at once. A third option is to be separated, but any given web server could have a mod_love type module written for it. This could share memory with the love server process. So tighter integration is an option, but they can work apart. Changes happen in this shared memory, driven by the command pump in the love server. Lspace just needs read access, and just serves the current state of the world. Love server persists to disk when it's ready to, though the shared memory can just be memory mapped files. This is the best of both worlds, excuse the pun. Thoughts about directory structure. ======================================== A major goal is to have the disk structure of a sim (and inventory) be decently human readable. The assets should be stored as normal files of the appropriate type, so that they can be edited with normal editing software like blender, gimp, a text editor, etc. Other goals include not duplicating assets, and making it easy to move assets around. Names. ------ A major LL created problem is that in world objects can have the same name, though stuff in an objects inventory is forced to have unique names by automatically adding numbers to the names. In inventory you can have stuff with the same name to. The same named objects don't have to be the same object, they can be completely different. A simple object name to file name matching, with directories for contents, just wont work. Need to munge the names anyway. All name munging should produce names that are compatible with various OS file systems, compatible with URLs, add "_123" numbers at the end for duplicate names in the same directory, and auto add a file extension if one is missing. Probably should check the file type if there IS a file extension. Links and URLs. --------------- Any asset file could be a stuffs.lnk file, which holds a relative path name or full URL pointing to the real asset. An external lspace server would return the .omg file when the stuffs URL is requested, or an actual asset file when those are requested. Would have to do copy on write for editing and other state changes, not including script state changes. Probably need to store other info in the .lnk file if it's a URL, SHA-1 of the original file, other web cache info. Which starts to encroach on web proxy / cache territory, which we may not want to do, since we want to use real ones instead of crappy LL cache. Actually, file names / URLs in .omg files would mostly be relative to the file name / URL of the sim, and all the way down, so relative to the directory things are in. It's up to the client to keep track of where they are and build appropriate full URL / full path file names. UUIDS. ------ Original LL UUIDs are the usual 36 byte string representing 32 lower case hex characters and some dashes, encoding a 128 bit number. I was inspired by git using SHA-1 hashes for content addressable assets. SHA-1 hashes are 40 character hex codes representing 160 bit numbers that are calculated based on the content. So the same content will give the same SHA-1 hash. Git has proved that you only need the first digits of the SHA-1 hash to ensure uniqueness, so it's feasable to use only the first 128 bits of SHA-1 hashes to squeeze it into a UUID for the purposes of uniquely identifying assets. Precisely what git does. This means it could be backwards compatible with LL's use of UUIDs. Since the SHA-1 code of identical files is the same, we could use this to reduce duplicated large assets that never change, like textures and sounds. This will be a big win. I think we can get away with not storing SHA-1 hashes permanently, just use them for in memory references, but cache them to disk separately. The caches can be recreated at any time, since the SHA-1 hashes can be calculated based on the data in the assets. So no UUIDs stored in .omg files, just relative file / URL friendly names. The UUID / SHA-1 hashes are mostly for keeping in memory as keys to stuff, coz they can shrink down to a long long 128 bit integer. Each asset file, whether texture, script, mesh, text file, etc, comes with a matching .sha1 file that holds the SHA-1 hash of that file. .lnk files get hashed to, so that each copy of a linked stuffs gets it's own SHA-1 hash, but in this case the "content" is the relative path name. The .sha1 files of the real asset .lnk files point to can be found in the same place the real asset file is. Hmm, this means that reference counting will be needed, otherwise the one real copy of an asset can get deleted while links still point to it. There will be a .sha1 directory full of files with the SHA-1 hashes as part of the name, and the rest being similar to a .lnk file, a path to the asset or .lnk file. Would save love server needing to keep that all in memory all the time. If the file system date stamp for the asset file is later than the one for the .sha1 file, then someone edited the file, recreate the .sha1 files. All the SHA-1 hashes can be recreated at any time, using file system date stamps to tell if one is stale. They are only used internally to a running system, to pass small identifiers around, and to fake LL UUIDs for LSL scripts. When a SHA-1 hash is calculated for a new asset, it gets stored in the .sha1, but if it already exists in .sha1, then the asset is replaced by that sha1.lnk file, thus automatically deduplicating assets. Reference counting. ------------------- Dunno yet, just realised the need for this, will come up with something soon. Will solve this problem when we implement links, wont need it until then anyway. Obviously the count has to be kept with the real asset file, there's a few ways to go about that. I've been thinking that the .sha1 file might be a good place to keep other meta data, like perhaps owner and group info. So one way is to include the reference count there to. Another option is a separate .ref file with the count inside. A third option, just tack the count onto the end of a file name. This is likely a bit quicker than updating a file. On disk structure. ------------------ "some sim name" -> some%20sim%20name/index.omg list of stuffs rezzed in the sim stuffs position, size, and orientation relative file / URL name pointing to the stuffs no need for the in world name, those interested in that will likely grab the stuffs.omg file anyway "a stuffs" -> a%20stuffs.omg in world name, description list of stuffs similar to the sim index.omg, only this is for the various meshes that make up this stuffs. stuffs position, size, and orientation, relative to this stuffs relative file / URL name pointing to the mesh and textures extra info for each material a%20stuffs/ directory files that are the contents of this stuffs could be .lnk files .sha1 files a%20stuffs/index.omg used to be a list of content file names, type, and UUID file names are right there in the directory UUID ala SHA-1 can now be calculated based on those files and stored in an asset.sha1 file type can use the magic/file/MIME system to identify file types can get rid of this file, though maybe have it in a .types directory, coz we would want to cache the file type or just use a poor mans magic/file/MIME thingy based on file extension, since we only have a small number of file types note cards should have a .txt, scripts a .lsl or .lua People could even be free to use their own organising directory structure. A directory for ground level, and one for each sky box for instance. Relative paths inside .omg files sorts that all out. A sims index.omg file might be constantly updated for busy sims. Could generate it on the fly by the lspace server, based on the actual contents of the sim directory. Alternative lspace servers could just use a CMS system for all of this anyway. They would still use the same structure for URLs and .omg files. Avatars. -------- Storing avatars in this way isn't such a good idea? Avatars could have their own avatar.omg dealing with shape, skin, clothes, attachments, etc. But instead of a client asking for a list, avatar arrivals and departures are driven by love. Though try to keep avatars as "just ordinary object, but with a person controlling it". Still, they move around a lot. Avatar.omg would live on the users hard drive, but sent to the love server on login, and after any change. Misc. ----- Right now I'm using Lua style .omg files, but eet would be a better choice I think. Saves having to write a Lua table to C structure system, which eet already has, sorta. Lua tables are at least more readable while I consider the design, but likely use eet instead when I have to write code to read the suckers. .omg files are managed by the love server, so fiddling with them is an expert thing anyway. Should have a tool to validate a sims files and recreate the caches. Remaining issues. ----------------- Owner / group UUID might be better dealt with elsewhere? Coz links. Also, we wont replicate the LL user / group stuff exactly, but morph into more standardised variations. Jabber users, jabber group rosters, OS users, LDAP users and groups, web site users, etc. So just provide an abstraction, and an example or two. might be better to move compiled scripts and generated Lua source to the LuaSL server's own private store? LuaSL needs to assign UUIDs to compiled script binaries, so it knows which running script is which coz there might be lots of copies of scripts on the other hand, each copy is uniquely named inside some objects contents, even if it's a link, so the UUID of the stuffs plus the UUID within the stuffs contents, for this copy / link of the script should suffice?