reserved attributes

Submitted by Trispis on Mon, 2004-03-08 12:45

I have been intermittently refining my installer for the warpedcore cron (for details, ref: most recent innovations conference presentation).

Two issues have sort of emerged (in my mind) from this refinement process.

1) purifying the cron concept (i.e., making sure that the installer only does things necessary for the cron itself, independent of any warpedcore ideas I may also have),

and as a direct result of that,

2) ways to extend the cron into the itbg discussed vision.

There's also a third issue that tends to arise every time I do an installer, and it is this issue thing I want to discuss (now having teased you with my cron, which is really irrelevant to this).

Every time I try to create an intelligent (self-monitoring, featureful, whatever) installer, there's one thing I keep concluding as 'necessary' -- an attribute on the player... a place to store and/or update installation status data.

And every time I think of this, I encounter the same problem...

What if the player happens to be using (regardless of how remote the possibility is, it nonetheless exists) the attribute name I'm using in my installer?

So, I've written a version which tries to determine a 'safe' attribute name from a limited selection of options (e.g., A B or C), as a solution for this. Specifically, to temporarily store 'their attribute contents' somewhere else while I use my static attribute name for my installation purposes (and at the end of the installer, I move their contents back).

What I'm wondering is ... is there any way to get a pulse on the MU* community to determine if "<an attribute reserved in some way for installers>" is a desirable and/or feasibly implementable fixed feature.'

At present, I am only thinking of a single reserved attrib; but, for the sake of general inquiry, it's probably appropriate to consider a larger scale implementation (a set of standardized reserved attribs for technical use/needs).

I discussed this with Javelin on M*U*S*H, and he proposed some ideas. I've included his input below.

* From afar, Javelin [...] can think of at least one algorithm for generating an attrib that's not on the current player for sure. Or, [if] this is for admin use, you could do an attrib tree rooted at [<string>`].

* From afar, Javelin would be inclined to suggest the attrib tree approach a la "registry". Attrib settable only from port descriptor is kind of a nasty hack.

* Javelin pages: Well, you could promote a conventional attribute hierarchy called "EXTSYSTEM" or something, and have people who write external systems claim a subhierarchy with their name (TRISPIS) or system name (WARPEDCORE), and then use an attribute named EXTSYSTEM`WARPEDCORE`OBJS or whatever. If God does @attrib/access on EXTSYSTEM to make it wizard-only or whatever, mortals won't be able to muck with any of the attributes beneath that label.

* Javelin pages: You still have a problem on sites where someone's using EXTSYSTEM`WARPEDCORE already, but that seems more than highly unlikely.

* From afar, Javelin was going to write an object integrity checker using a similar principle, actually. Each object's attrib would get hashed with SHA() and then the hash stored under SHA`, so you could quickly see if any attribs had changed since you last generated the hashes.

* From afar, Javelin *could* see a point in a hardcode function like tmpname(obj) that would return a valid unused attribute name for obj.

* Javelin pages: But it wouldn't return the same name every time, necessarily.

* From afar, Javelin (also knows how to softcode such a function)

* Javelin pages: Do you just need an attrib name known not to exist, or does the same name have to persist over time? (Answer: for my purposes it only needs to persist for the duration of the install, but I can certainly envision more extended duration needs).

* Javelin pages: Well, you can secure ~ as a special on a per-game basis, obviously, by warning Gods to use @attrib to do so. That's a bit specific to put in the distribution, though

* Javelin pages: [...] The @attrib command would be something like: @attrib/access/retroactive ~=wizard

* Javelin pages: The certain safe attrib algorithm is pretty simple. Sort the existing attribs by length, and iterate through them from shortest to longest. Make your new attrib name by taking the n'th character of the n'th shortest attribute and incrementing it (A->B, B->C,... Z->A, similar for symbols). If there is no n'th character of the n'th shortest attrib, assume it's an A. When finished, check to see if the attrib is on the object. If so, add an A to the end and check again (if it's still on the object, you lose, but that's highly pathological, as it means people are using extremely long attrib names to screw with you.)

* Javelin pages: The concept of that algorithm is you're creating an attrib that's known to be different from the first attrib, known to be different from the second, known to be different from the third, etc.

* SYNC: Mon Mar 08 10:05:00 2004

attribute trees are presently part of the development branch and about to be merged into the stable branch (see Jav's latest post about this), so now might be a very good time to be investigating these options in that frame of reference.