Automating Resource Allocations

I think it is a good idea to automate the resource allocation scheme. That way the person requesting a resource allocation will get an immediate response.

Allocate would maybe have an extra field perhaps an API key?

A button say called make request could be then pressed and it would send the details to a server with a database of allocated resources and if not already present reserve and inform the user allocated or not

Garbage collection you mean? Oh that kind of resource. Seriously, the problem is not with allocating resources but with reclaiming them when software dies. There are many ways that happens.

I have found that the response to an Allocate request has been prompt and helpful.

I have found that the response to an Allocate request has been prompt and helpful.

and probably more resistant to abuse than an automated system as described.

My own allocation requests have been few and separated by many years. Like Chris’s experiences, the responses were prompt and helpful.

probably more resistant to abuse than an automated system as described.

As a matter of record, have there been any abuses? I do not want to turn over any stones best left undisturbed, but I am curious.

As a matter of record, have there been any abuses? I do not want to turn over any stones best left undisturbed, but I am curious.

If you asked at the allocate email address you may find out. To be brutally honest, if a system with an amount of trust exists, so does an ars***** that will try to exploit it.

As a matter of record, have there been any abuses?

Since it’s always been a human-controlled system, the answer must surely be no. But things that are automatic – forum posting and news comments – have been very much abused.

The system must remain non-automated.

The system must remain non-automated.

This.

Any automated API would require accounts and authentication and so on, which would act as a barrier to entry for new developers and probably reduce take-up of the system. If it didn’t have these, it would be wide open to all kinds of abuse.

The current system works, and isn’t onerous; allocation requests are replied to quickly. Anyone can send an email in, so long as they have a copy of Allocate.

There are plenty more things which actually need fixing.

I can see several problems with automating allocations:

1. Some resources are finite, for example 8-bit filing system numbers and 12-bit filetypes. Those have to be rationed. Arguably work should be done to extent the scope of those fields, but that makes them incompatible with previous OS versions. I have in the past handed back allocations of these so they can be reused.
2. Junk allocations, that clutter up the database but are never going to be used.
3. Mining the database. Allocations have always been private, so you can’t see what your competitor is working on. Allowing an instant response to an allocation means someone can make allocations fishing around to see if a name has already been taken, leaking information about what might be being developed. That would also increase the number of junk allocations.

Possibly some of those could be addressed by rate-limiting or suspense-periods or whatever, but roundtripping via a human is a better filter. Assuming there is a human willing to do the work, of course.

For finite resources, perhaps allocation could come with an expiry date – if your software isn’t released by say 2 years after allocation, you have to respond to renew your allocation for another 2 years. That’s something where a bit of lightweight automation could come in handy.

Arguably work should be done to extent the scope of those fields, but that makes them incompatible with previous OS versions.

I remember a discussion a few years ago about extending them to 32-bit, while retaining the existing 12 bits as a ‘hint’. For example, a new database app that only needs to run on the current OS might get the allocation &10000FFD so that it still ‘inherits’ from &FFD (Data) and therefore appears as a Data file on older OS versions.

Of course, it’s easier said than done!