1 files changed, 117 insertions, 0 deletions

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