Move the latest thoughts about directory structure into the love docs, add more, and clean them up.

1 files changed, 0 insertions, 115 deletions

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