Quota, Recycling, Expiry and the Trashbin in v5

This document describes the free quota system and issues related to recycling and deletion of objects, including the trashbin system.

1. Quota

Running out of quota is an annoying thing to experience. Each builder has a given amount of usable space, and the permission to build new objects ends when

  1. there are too many unmeasured objects in the builder's inventory, or
  2. all the builder's objects surpass the given amount.

Although quota might be augmented, and the default initial amout of quota might be raised (both actions by wizards), this is easily forgotten. The problem is often not realized and/or encountered before right in the middle of something, when there is no wizard available.

Building new objects may be going to the Xpress Create window and creating a "thing" which is given a name and a description. But it may also be the automatic creation of a note when starting a new log on a recorder. This fact, or notion, is not easily conceived by everybody. There are many teachers who want to start recording a session with their students, but couldn't, because of one of the two situations mentioned in the first paragraph. In despair, many of them quickly recycle old logs, in order to reduce used space and to record the session to be held. But "recycling" in MOO- language means: delete completely and irrevocably.

The quota feature was meant to prevent the MOO database from bloating. But technology has made huge leaps since the quota feature was introduced in the early days; both storage space on the server, memory to handle databases and prosessor power have increased exponentially. And on the other side, we began to make serious educational use of the MOO. This included using the recorder on a regular basis, for long sessions, making logs which should be kept for a long time, since they had documentational importance.

These facts (need for logs, people panicking, logs getting lost, server power) made me introduce the optional free quota property in v5.

The property is set on the $builder, meaning that each builder can have free quota or not. It defaults to true (meaning: free quota is the normal case.) Of course, builders can't change their own setting, but two player classes can: Wizards, and the new Teacher Class. A teacher can change every other builder's setting, including his own. This means that builders may have free quota, while teachers and wizards always have.

1.1. Setting

Quota may be set through web. The quota is visible in the tab "quota" in the Create/Organize window. Teachers and wizards have the option to "change the player" (drop down menu) and set both their setting (free quota or not) and the amount of quota, while normal players would just see the amount of used, free and allowed space.

Quota may be set through web

1.2. Counting and Measuring

When building, the builder's objects are automatically and quickly recounted, and the new balance is used. There should be no "Sorry, out of quota" because of unmeasured objects any more. There is no need for the old command '@measure new' any more. The same goes for looking at the quota on the web: when looking at the quota page, all objects are recounted, thus giving the correct impression of the balance. The graphic showing used space is now accurate by 1/100th.

How does it work? The easiest thing would have been to go to $quota_utils:creation_permitted and insert a "return 1;" at the beginning, allowing all and everyone to build any number of things. But that would have meant no option to keep the quota system. Instead, when $quota_utils:creation_permitted is run, it

2. Recycling

As mentioned in the above section, recycling in MOO-language means completely and irrevocably delete. This is counter-intuitive to many modern users. Almost all other computer language uses the term recycling as something temporary. Many new users aren't aware of the fact that recycling in MOO is irrevocably. And in panic situations, they often don't keep their head cool enough and copy-and-paste documents to other text editors before recycling the document - even if they know of the consequences.

It seemed appropriate to change the working and the wording.

2.1. Working

I introduced a personal trashbin in v5. Instead of deleting an object right away, it is first sent to the trashbin. The trashbin takes over full ownership of the object, thus freeing the builder's quota for exactly this amount of space. So even if a builder has limited quota, in case he runs low on it, he may temporarily recycle other objects, and begin, e.g., recording a session. Recycled objects are not readable to even the former owner, but they can be restored, i.e., given back to the former owner if the quota permits it.

2.2. Wording

I therefore propose (and have already made use of it in v5) three distinct words:

3. Trashbin

3.1. Selection page

The inventory tab in the Create/Organize Window displays checkboxes on all objects. These can be ticked to form a collection of objects. As with all checkboxes in v5, these are labeled, i.e., the box is may be checked by clicking the text next to the box. The number of objects to be shown per page can be set. Wizards can choose thousand if they want or need to. Wizards (and wizards only) have the "all objects" tab as well, showing them all objects in the whole MOO. The "all objects" tab has checkboxes as well. Objects can be walked through a thousand at a time, to clean up test objects and obsolete stuff. Wizards may act on behalf of other players.

Multiple objects can be chosen and recycled at once

This collection may be recycled all at once. When hitting the "recycle" button, the form is sent to the server, where each object ticked is checked for several facts:

In these cases, recycling is not permitted. Furthermore, if the object is an exit or a room, it cannot be recycled, but must be deleted.

3.2. Confirmation page

The next page shows warnings and explanations, and a confirmation is required before proceeding. Only recyclable and deletable objects make it to the confirmation list. This confirmation page fills a severe security hole in previous Xpress versions (which I have described elsewhere).

For security reasons and convenience, there is a confirm page

Often, when someone wants to get rid of a room, a binder, a recorder or a container, one wishes to get rid of the whole contents as well. The confirmation page takes this into consideration by offering recycling for each recyclable item in the contents path. Meaning, for every level of content ("a box in a box in a box", in respective indentation levels), all owned objects therein are displayed with an unticked checkbox. The normal cascading case is the contents property. But for a range of objects, other paths must be used.

Only the originally selected objects from the selection page are ticked. By ticking the appropriate checkboxes, one can make the selection even greater and more complete, avoiding the tiresome process of repeating recycling for every object. At this point, objects are still clickable and viewable in the web frame; meaning that one can check object by object if it should be recycled. This makes cleaning up the MOO a fun procedure.

3.3. Result page

When hitting "recycle", the form is sent to the server, where a number of actions are performed. Ownership is changed to the trashbin, shared owners are removed, all builder's shared object lists are searched and the object removed from there, the key override property is deleted, the object is locked, contents is moved to their respective owners, all search results from the search tab of al users are checked, and if this object is in the hit list for a search, it is removed from there; if its a room: in case someone had the room as its home, this player's home property is changed to $player_start (and if connected and in this room, this player is notified and moved to his new home), the whole MOO is searched for exits which might lead to or from the room, those exits are deleted, if it's a forum, members are removed, if it's a bookmark on a player, on a group or globally, it is removed from there, etc. etc.

A thorough list of actions taken upon recycling is shown

3.4. Restore and delete

Once in the trashbin, objects may be either restored and sent back to their former user, or they may be deleted. The trashbin table is broken down to the "number of objects shown" per page like in the inventory and search tab. It is sortable on all colums, both up and down.

The trashbin is sortable and can restore or delete its contents

4. Expiry date

Going over the MOO, I realized that there were many outdated documents floating around. Some documents just got older, and there was no way to know when they would be obsolete. But many of the documents were deemed to expire at a time known beforehand. There were welcome-letters to students, information about exams to be taken for one class, time tables, etc. Many of those documents were distracting and misguiding students.

I therefore made an "expiry" feature. Documents can now be scheduled to be recycled at any given time in the future.

The expiry date feature is defined in a way that virtually all objects can be recycled at a given time. For now, I have included it only on the document, since that was the most urgent object class to expire. It may be extended though to other objects. It may even open for a new type of object involving role play and other games ("task: find the hidden document before it dematerializes").

Documents can be scheduled to be recycled at any given time

The second an object expires, nothing really happens. But there are two things that can make the object disappear after that date:

These pages are put together by different mechanisms. They check if the object in question is going to be displayed or not. That really means that an object will be recycled on the first occasion someone is requesting it after its expiry date. Requesting is here a technical term; most often, would not even be aware of the fact that the object is being requested.

Recycling means: Move to the Trashbin. All actions are taken that are normally run when an object is moved to the trashbin. In addition to that, and for convenience, the Trashbin sends a mail to the object's owner notifying him that the object has been recycled, and what measures had to be taken in order to clean up.

Please be extremely cautious when expanding this feature to non-recyclables like rooms. I don't think deleting (i.e., permanent, irrevocable deletion) should be scheduled.

For convenience, the Trashbin 
sends a mail to the owner notifying him that the object has 
been recycled.

NOTE. The ultimate date for expiry is Tuesday, January 19th, 2038. On that day, enCore (or: the lambdaoo server), like most other Unix-based systems, will reach its highest number with which to code time, and switch time back to Friday, December 13th, 1901, counting time all over again. (The "Friday the 13th bug".) By then, we might have moved on to v6. Given the time I used for moulding v5, this remains highly questionable though.


Will there be changes to these features and functions?

Maybe these changes will come soon, maybe not. I don't know, sorry.

(End of file)