When I used to think about these properties, I would consider doing something like "check both $site.user_max_obj and the player's this.max_obj value", but that's mighty ugly (and certainly not object-oriented). Then I realized there might be a pretty simple solution:

• Create a new standard object (probably named $var on object #0), and move properties to that object. So other standard verbs will refer to properties like $var.yesterday instead of $core_times.yesterday. I plan to have $var object be the last object in the range of official lilycore objects, i.e., #99.

Well, 20 days have gone by, and I've spent a lot of time working on other improvements to lilycore (and writing a lot more for this wiki than I usually do!), but I haven't written a single new line of code towards this goal. I did have some clever ideas for implementing this, which I think would have also made it easier for people to upgrade to this lilycore from some older lilycore. But now I'm worn out from the other lily projects, so I think I'll just "get this to work" in RPI's core, and distribute that as the official release (hopefully soon!). So, this reorg-properties-to-support-sites project probably won't make this upgrade easier for anyone, but hopefully the changes will make it easier to upgrade to the next new lilycore. I also probably won't get to the special $site.player and $site.disc ideas in time for this release, unless we give up and wait another year. There's too many other things which need to be sorted out before an official 2.8.0 release can happen, including some bizarre problems compiling LambdaMOO that I wasn't aware of back in November. -- gad/Dec 26/2005

-- Initial text from: GaranceDrosehn

• The $site_defs.new_site() verb could also go thru all existing users and discussions, and re-parent them to the site-specific $site.player and $site.disc objects. I've tried this on a test core, and it seems to work fine. I need to do some more testing of it though.

Then there's the property values which change over time for every core. For those:

So, what I want to do is:

• Find all properties which seem to be site-specific, and move them into a new object (right now I tend to pick object #80). This object will be named the $site_defs object (on object #0). It will contain the "correct" values of these site-specific properties for the distributed lily core. Many of these properties are currently on object #0, but some of them are on other standard objects.

• When someone wants to install a lily server, they will start up a snapshot of that distributed core, and give a command something like $site_defs:new_site(...) . This will create a new object with a higher object number that $site_defs, and that object will have $site_defs as it's parent.

• There will be another variable on object #0, named $site . The distributed core will have $site equals $site_def , but when you create a new site it will change the value of $site to be the newly created object. All verbs will reference these properties as $site.somename . When someone at a site goes to do something like $set site_name my_company , it will change the value in their site's object, and not in the $site_def object. The $set command will check for $site equals $site_def , and will not allow changes to be made to it (not easily at least).

• Note that at this point, the distributed core could contain the site-specific object for multiple sites. Then when you get a core, you could just change which object is pointed to by the main $site property. I'm not sure I want to do this, but it might be convenient.

So that cleans up some of the "always-different" properties which get in the way when I'm trying to compare two cores. The thing is, there are some site-specific properties which have to do with limits on users, or on discussions. Right now those properties are on $player (#6) or $disc (#10), and that is the right place for them to be. These are values where the site-specific value is sometimes overridden for a single user or discussion. When I used to think about these properties, I would consider doing something ugly like "check both $site.user_max_obj and the player-specific value", but that's ugly. Then I realized there's a pretty simple solution:

• Have $site_defs.new_site() also create a site-specific object for player, which would use the distributed player-object as it's parent. Rename $player to be $player_defs . And then create all lily users as children of $site.player , instead of $player_defs . Do the same with $disc_defs and $site.disc (or some similar names).

• The $site_defs.new_site() verb could also go thru all existing users and discussions, and re-parent them to the site-specific $site.player and $site.disc objects. I've tried this on a test core, and it seems to work fine.

So, that handles the site-specific values. Then there's the property values which change over time for every core. For those:

• Create a new standard object (probably named $var on object #0), and move properties to that object. So other standard verbs will refer to properties like $var.yesterday instead of $core_times.yesterday .

I have further ideas along these lines, which I haven't had the time to write yet...

So, any thoughts on the above plans? I already have some initial stabs at this, enough so I'm pretty sure this will work the way I want it to work. My intent is to try and do it this way, unless I hit a real stumbling block. I just might have something ready before Jan 1st 2006, if things work out okay. I doubt I'll have all the changes implemented, but I'll have enough done that I'd finally feel comfortable doing the official release of a new core (after fixing the other details still on the to-do list).

-- GaranceDrosehn - 06 Dec 2005