> In a conventional capability system, the capability *is* the designation
of
> the object it refers to.
This depends on whether the system is partitioned or not. Strictly speaking, in a partitioned capability system the designation is of the "slot" in which the capability resides. That is, there is one added level of indirection.
I am beginning to suspect that the source of confusion in the discussion rests on what may be a confusion about the primacy of file-system names as opposed to object designators. By "name", I mean a string that is (conventionally) handed to a file system via an "open" call in order to obtain a file descriptor. By "designator", I mean either a file descriptor or a capability depending on what systems we are talking about. Note that the operating system (equivalently: the runtime) need not know *anything* about names. It can operate purely in terms of designators. There is no reason why one mapping of names to designators is better than any other, provided that all protection decisions are made at the designator level.
The wildcarding approach, unless I am terribly confused, works on names rather than designators. It therefore places protection at the level of names rather than designators. If so, the resulting system is not a capability system at all: a critical protection decision appears to be omitted in the designator layer of the system architecture. There is no harm in *also* checking things at the name level, but this is perilous. Once a designator is obtained it may be held for an arbitrarily long time.
In real system construction, however, there is a problem with being purely designator driven, which is the "boostrap problem". In the absence of persistence, determining who gets what initial capabilities at powerup is distressingly hard to get right. Ultimately, this is *why* we have built file systems into most conventional computing architecture.
Is there any light here, or am I just adding to the murk?
shap