Subject: Quota

From: Kent M Pitman <[email-masked]>
Date: Tue, 3 Aug 1993 04:15:00 -0700

I have a strong hunch that the way to solve LambdaMOO's quota problems
is to do real-time tracking of real quota.

I think it would be an interesting thing to test to have the server
allocate room in every variable-size object (including low-tech objects
likes lists and strings) which maintains its size (including recursively
held copyable parts--i.e., things not type OBJ which are copied every
time you move the object around).

If you assume (and this is just a complete guess) that the average
object is of size 6, then keeping this count would increase the size of
objects by, let's say, 15%.

If most operations that copy objects don't change their size, then the
size doesn't have to be computed much.  And for those that do change size,
the size would be trivial to calculate if already maintained recursively.

Then you could make it so that quota was maintained at object-slot-store
time.  Slot assignment doesn't happen so often that this check would seem
prohibitive.  It would obviously have to be much bigger since the units would
be smaller than quota now.  But it would be fair.

If the savings that fair quota administration achieved was at least the
supposed 15%, it would pay for itself.  If it wasn't, then we'd have the
satisfaction of knowing that probably quota was just hopeless and we
just shouldn't care or should be completely arbitrary.

It would have the nice property that we could figure out how to resolve
the recent scuffle over whether various mailing lists cost the Moo too
much space compared to other space-taking things that people get charged 
serious quota for and have to pester the ARB for approval of.

I think it's an experiment worth trying.  (Especially since I wouldn't
be the one to implement it and it costs me nothing to say so... :-)
Oh well.  Anyway, I figured I'd at least suggest it...  I don't plan to
pester for it if Lambda or somebody adventurous doesn't instantly warm up
to the idea.  But I wanted it to be on the books.

(This is mostly a Lambda-specific problem I'm trying to address, but
maybe it affects other Moos, too.  Anyway, it can't be done without
server support, so this seemed like the mailing list to use.)

---

From: Larry Masinter <[email-masked]>
Date: Tue, 3 Aug 1993 10:14:04 -0700

I don't like the idea that random assignments could generate errors.
It would make safe MOO programming impossible. (It's difficult enough
to not be able to easily test if something is going to run out of
seconds or ticks...)

---

From: Kent M Pitman <[email-masked]>
Date: Tue, 3 Aug 1993 11:24:00 -0700

Date: Tue, 3 Aug 1993 13:14 EDT
    From: Larry Masinter <[email-masked]>

Hmmm. That's an issue.

The right answer there is to become more transaction oriented, perhaps.
I suppose in the face of I/O you might in principle do that by buffering
all the notify's until you were sure the rest of the thing was gonna
succeed... Or by defining that a commit had occurred before the first
I/O happens.  I always try to order my code that way anyway--with the
store into a variable preceding the tell information saying that it's
occurred.  Well, I admit this paragraph suggests things that are way too
large to be practical as a quick hack, though.  Still, I would like to
see the MOO someday have a stronger transaction concept.  Among other
things, it might improve db reliability in face of crashes...

What might work in the quick[er] hack family, though, would be to make
it a verb option (like "x" ... perhaps called "q") which determined
whether this checking was enabled.  Perhaps defaultly no, but @create,
@program, @property, and a few others (e.g., mail delivery subroutines!)
might do it...  (And eval...?)