consider moving all internal tables to an internal namespace

[holic]

We already namespace tables like mudstore:schema, it'd be great to do the same treatment to NamespaceOwner, InstalledModules, etc. I wouldn't mind these living together under a mud or mudinternal namespace or creating namespaces for each type of thing, e.g. mudstore, mudworld.

Ultimately my goal is to clear the root namespace for users and to make it a bit easier for us+users to know when they're looking at user-defined things vs mud-internal things.

[dk1a]

depends on #734 (world systems need to retain root namespace)

[holic]

world systems need to retain root namespace

why?

[dk1a]

root methods get registered with just their name
non-root methods get prefixed with the namespace
so I assume we want short method names like grantAccess, not mudnamespace_grantAccess for all the core API
and unlike tables, the internal system API is not quite as useless to end-users, not quite as distracting on the frontend (maybe)

[holic]

I know that access control is somewhat tied to the function selector pattern (to determine namespace etc without an extra lookup) but I wonder if there's some special treatment we could do to world methods where we get best of both worlds (namespaced internal tables, non-namespaced world methods like grantAccess).

That said, I feel like mudinternal_grantAccess isn't bad either and very explicit that you're reaching into mud internals/interacting with mud APIs.

[alvrs]

since we register all tables and systems in the CoreModule, it should be easy to move their mud config namespace to eg world and still register the system function selectors in the root namespace, and give the systems access to the world namespace.

[holic]

I just took a stab at this and it's going to be a bit more involved than initially expected. Once I added a namespace to World's MUD config, it prefixed all system methods with that namespace, thus changing the interfaces, which bubbles up to IBaseWorld, which a bunch of internal stuff uses.

Some possible next steps:

• add namespace support/overrides to config for tables (see Add support for multiple namespaces in one config #994)
• separate MUD configs (we'd need to add support for this)
• don't use codegen for world systems?