From 7aebe31eba4cae2f90a4a682684ee05359091e7c Mon Sep 17 00:00:00 2001 From: David Walter Seikel Date: Sat, 24 May 2014 14:25:23 +1000 Subject: More notes about stuffs directory structure. --- src/libraries/love.h | 117 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 117 insertions(+) (limited to 'src') diff --git a/src/libraries/love.h b/src/libraries/love.h index a28872a..f951a89 100644 --- a/src/libraries/love.h +++ b/src/libraries/love.h @@ -151,6 +151,7 @@ typedef struct _loveStuffs love server starts up scans sim disk structure looking for scripts in stuffs keep track of which script is in which stuffs + hashed by stuffs uuid, store pointer to script structure -> LuaSL compile script -> LuaSL load this saved state -> LuaSL run script @@ -186,4 +187,120 @@ Extantz client starts up send update nails commands to everyone/thing watching */ + +/* More 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. + +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. Perhaps the automatic adding of numbers thing would be best? +All names have to be coerced into operating system friendly names +anyway, so there still needs to be some sort of mapping between objects +and their names. Not to mention URL escaping for names to. Try to +combine both. + +Should have a tool to validate a sims files. + +Sooo, directory structure of a sim - + +"sim name" -> sim%20name + index.omg + lists objects in the sim, with details about UUID, position, orientation, and size + maps in world name <-> file name / URL name + actually use file:// style URLs, so that we can pass them to clients, + and have the posibility of pointing to assets on some other lspace server + the name is a duplicate of what's inside the objects .omg file + Should try to keep these in sync automaticallly + sim index.omg files are managed by the love server, + so fiddling with them outside is an expert thing to do + "object name" -> object%20name.omg and a directory called object%20name + this file name could also be munged if there are objects with duplicate names + an external lspace server would return the .omg file when the objects URL is requested + .omg file contains file names / URLs of other assets like actual mesh files and textures + also UUID, in world name, description, owner UUID. + owner UUID might be better dealt with elsewhere? + coz links + directory contains the contents of the object + index.omg + lists the stuffs in the objects contents, with UUID and type for each + maps in world name <-> file name / URL name + the asset files, plus things like compiled script binaries and temporaries + 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? + except links + +Yes, this means that files and directories can be links in the case of duplicate assets. + Though the UUIDs inside .omg files would have to be unique? + Only for script binaries I think. + Would have to do copy on write for editing and other state changes, not including script state changes. + So links to object .omg files would all have the same UUID. + Which works well with using sha-1 content addressable assets. B-) + +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. + +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. + +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. + +Storing avatars in this way isn't such a good idea? + Avatars could have their own index.omg dealing with shape, skin, clothes, attachments, etc. + But instead of 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. + +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. + +Might be useful to have a UUID -> asset file .cache directory, or +something similar? Could save love server needing to keep that all in +memory all the time. Plus, an issue with using sha-1 UUIDs and keeping +them inside the .omg files is that this changes the sha-1 hash. Should +think about keeping uuid's outside of them. Perhaps a .sha1 file along +side each .omg file and asset file? Don't bother with links, if an +asset is a link, just look for the .sha1 file where the real file is. +The UUIDs are mostly for keeping in memory as keys to stuff, coz they +can shrink down to a long. On the other hand, duplicated objects still +need their own UUIDs to refer to each copy / link. Sha-1 the relative +path to the link? It all gets trickier when assets are on different +lspace servers, not to mention some OSes don't support links very well, +or at all. + +objectName.omg + objectName.sha1 In each of these cases, the .sha1 file is the sha1 sum of the file it goes with, not of the file it points to. +objectName.lnk + objectName.sha1 .lnk is a relative file name to objectName.omg +objectName.url + objectName.sha1 .url is a URL to a the .omg on a different server + Probably need to store other info in the .url file, sha1 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. + +.cache + sha1 as file names of .lnk or .url files. + +If the file system date stamps are different, then someone edited the file, recreate the sha1 files. + Which implies that lengthy sha1 calculations need to touch the file once done. + +*/ + #endif -- cgit v1.1