This is the Observer Pattern for Entities in the Universe Web. The NI model is of a single, universal pool of Entities aware of each other's state. An Entity expresses its interest in another and, if permitted, can then read that peer's state. In addition, it is notified of changes in that peer's state; until it loses interest.
Entities are considered to be 'live', with four interface points: they can read and change their own state, they can read another's state, and they can be notified of another's change in state, including the fact that they're watching back...
NI is protocol-independent: i.e., it doesn't depend on the NP Entity Protocol and needn't even see an Internet connection - NI Entity Interaction may occur in-process.
UID: 23423-4141a This: is the content
Entities have a UID which is always sent in the headers. UIDs may or may not be UUIDs, but must be globally unique identifiers constructed from hyphen-separated hexadecimal digits. The headers look much like HTTP, and will share some HTTP semantics in NP. The 'Content-Type' is always a fragment of NR. In this specification, nothing much is said about the NR content part, only the headers. Both header and content parts follow this same Entity syntax. Basic Entity notation is like an ordered hashtable. Keys must be unique, so there is also a list notation - again, YAML's hyphen.
UID: 23423-4141a
View: - UID: ffda0-582ce
- UID: 11ab3-001a3
This: is the content
Which sends the following View Event to ffda0-582ce:
UID: 23423-4141a View: - UID: ffda0-582ce
The View Event looks like a reduced version of the viewer Entity, with only the relevant parts announced.
When it does this, the target automatically gets a corresponding entry:
UID: ffda0-582ce
Cast: - UID: 99a27-5510c
- UID: 23423-4141a
stuff: content
UID: ffda0-582ce
Cast: - UID: 23423-4141a
- UID: 99a27-5510c
Permit: - UID: 23423-4141a
quiet
stuff: content
It's only allowing 23423-4141a to view itself, and doesn't want to be notified of any change in that fact: with 'quiet', the permission is executed silently - a peer can View this one without it knowing, without it seeing the View Event above. The default is to report all View Events, and if there's no Permit entry, the attempt is reported but nothing is returned.
The UID can be set to '*' to set permissions for all peers. Only individual UIDs or '*' can be used, there's no way to specify groups any other way. NP will introduce host-level permissions, however.
Maybe this Entity wants to take a look back itself at 99a27-5510c, to help it decide what to do with its outstanding request:
UID: ffda0-582ce
View: - UID: 99a27-5510c
Cast: - UID: 23423-4141a
- UID: 99a27-5510c
Permit: - UID: 23423-4141a
quiet
stuff: content
Maybe it wants to deny 99a27-5510c without being bothered by it any more:
UID: ffda0-582ce
Cast: - UID: 23423-4141a
- UID: 99a27-5510c
Permit: - UID: 23423-4141a
quiet
- UID: 99a27-5510c
deny quiet
stuff: content
Nothing is returned until a Permit entry covering the Cast entry exists - either allow or deny.
Without an entry or with an entry that isn't 'quiet', all View attempts are reported. If set just to 'deny', this Entity will be told of every attempt by 99a27-5510c to access it just as if no entry existed, but the denial Cast Event will be immediate and automatic each time.
The following will default to initial automatic denial for all-comers (apart from the specific, overriding case of 23423-4141a), but giving notification to ffda0-582ce of each attempt anyway:
UID: ffda0-582ce
Cast: - UID: 23423-4141a
- UID: 99a27-5510c
Permit: - UID: 23423-4141a
quiet
- UID: *
deny
stuff: content
UID: ffda0-582ce
Cast: - UID: 23423-4141a
- UID: 99a27-5510c
Permit: - UID: 23423-4141a
quiet
Private: think-about: 99a27-5510c
stuff: content
Private data is any valid Entity notation content.
Here is the Cast Event that 23423-4141a sees - without all the fields it's not interested in, are obvious or it's not allowed to see:
UID: ffda0-582ce Cast: - UID: 23423-4141a stuff: changed
The 23423-4141a Entity can continue to access this state at any time, and again will only see this cut-down view.
If a peer doesn't have permission, is explicitly denied or has permission subsequently removed, it sees something like this:
UID: ffda0-582ce
Cast: - UID: 99a27-5510c
Permit: - UID: 99a27-5510c
deny
Again, the fact that it is quiet is removed as none of its business.. Notice that permitted peers don't get any Permit: entry reported, as it's obviously allowed.
In NI, header information always takes the place of notifying what in HTTP would be in the status code. The above permitted Cast Event is like a 200 OK, and the deny Cast Event is like a 403 Forbidden, for example.
Just deleting the View entry removes the corresponding Cast.
An Entity can return a unique state to a peer viewer. It can put either Content-Location or Location in its headers. In the former case, the state of this alternative Entity is returned, in the latter, not. [one-by-one in headers, or globally redirect *]
An Entity can send a state to a peer without it asking for it. It simply adds a Cast and a Permit entry to the target, which sends it a Cast Event. [must have View: - UID: * at the other end; can't have Cast: - UID: * 'cos that's God - or maybe omniscience and omnipotence mean similar things: just 'cos you say View: * doesn't mean you do see everything; just cos you Cast: * doesn't mean everyone sees you - only those with View: *? - only those in same host - NP?]
[2278]