User:Kevin Reid/Thoughts on protocol queries


 * This text has not been updated other than wikification and some quick notes since September 5, 2005. I make no guarantee that it reflects my current opinion on E's direction. —Kevin Reid 09:12, 6 May 2010 (CDT)

=Thoughts on extending protocols=

Scenario
Two CapTP peers talking. Let's handwave that the Miranda-method protocol is well-known and adequate. a sends.

b has Interesting Features that it wishes to express in its type object. How does b (or b's implementation language) extend the TypeDesc protocol in a way that will not potentially create confusion due to accidental overlap of method names with other extensions?

Idea
Have a common way of querying an object "Do you implement the protocol X", where X is a string(?) identifying the protocol. This does not, as the string is deliberately public, and is intended to be common knowledge. It is as "alleged" as the alleged type itself.

Proposal #1
Make PassByCopy ProtocolGuards. Their coercion behavior is to call/send __conformTo. An object may indicate support of a protocol (the protocol being discovered by extracting the public state of the PBC'd guard) by returning [self] (since __conformTo returns self by default).

(Alternate: use __optSealedDispatch and don't require tupling.)

Proposal #2
Again have PassByCopy guards, but stuff them in the supers field of the alleged type of the object in question (which in the scenario above is itself an alleged type!).

Advantages of this over #1: no slightly-funny business with __conformTo returning not-quite-self. Supers is a reasonably natural place to put this, as the ProtocolGuards do indeed designate supertypes.

Disadvantages: The type desc may be more expensive to retrieve across a network. Current E semantics makes it very hard to extend alleged types. (perhaps meta.context.getAllegedType?) No built-into-the-query support for coercion to protocols.


 * Later note: If the Signature plan goes into effect, supers may not exist or may not have the same meaning or lack thereof as it does now. —Kevin Reid 09:12, 6 May 2010 (CDT)

Potential formats of protocol names
DNS names      org.erights.e.elib.slot.Slot

Relies on the DNS system's stability - global namespaceish.

URIs           http://www.erights.org/elib#slot.Slot

Easier to create URIs than DNS names. Still relies on DNS.
 * Later note: The tag: URI scheme allows dating a DNS usage. Thus it relies only on agreement on a calendar. —Kevin Reid 09:12, 6 May 2010 (CDT)

One of the above combined with a GUID/SwissNumber

org.erights.elib.slot.Slot!09l64YiaLKTgV7Drnu_8QeQpYm9T

The advantage of this over the above is that the random component makes it unlikely to collide with other protocol names, even if, e.g., DNS names change hands. For normal use, the first part of the name should be adequate to provide human-readable identification, and in the event of a first-part-collision it is highly likely that the random characters will be different at the left end.


 * Later note: This style of naming corresponds to a concept I'm calling “Token” these days — an PassByCopy object which has a static random component and a human-readable component, and prints only as the human-readable component — they would be used for all 'enumeration type' purposes. —Kevin Reid 09:12, 6 May 2010 (CDT)

Of course, no matter what the name scheme, it is trivial to deliberately create a "collision", but this does not matter as it is always an alleged type and the object can misbehave any way it likes no matter what protocols it claims to support.

Not addressed
Means of finding authoritative documentation of a protocol.