From 58141bf77c37757811420f74db13a9f2e9db9e08 Mon Sep 17 00:00:00 2001 From: David Walter Seikel Date: Sat, 24 May 2014 17:02:30 +1000 Subject: Move the latest thoughts about directory structure into the love docs, add more, and clean them up. --- src/libraries/love.h | 115 --------------------------------------------------- 1 file changed, 115 deletions(-) (limited to 'src/libraries/love.h') diff --git a/src/libraries/love.h b/src/libraries/love.h index f951a89..f75d5e7 100644 --- a/src/libraries/love.h +++ b/src/libraries/love.h @@ -188,119 +188,4 @@ Extantz client starts up */ -/* 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