Prefix Maps

[oberstet]

Prefix Maps (CURIEs) serve two purposes:

• make it convenient for developers to handle URIs while coding (CURIEs are more convenient than unwieldly long URIs)
• reduce the payload on the wire

URIs can occur in:

WAMP itself:

• topic URIs
• procedure URIs

WAMP payloads:

• within the arguments of RPCs
• within the results of RPCs
• within errors returned from RPCs
• within events publishes
• within events received

Limitations

Currently, a Prefix for some URI set can only be

• established once (during a session) - cannot be changed later
• only be established by the client

Problems

When client 1 publishes an event containing CURIEs in the event payload, how does a client 2 know how to resolved those CURIEs when it doesn't have the prefix map of client 1?

Even if the server knew the payload structure of the published event and the prefix map of client 1, it needed to "reshrink" the URIs for each subscriber using that subscriber's respective prefix map.

That would make message dispatching to large numbers of subscribers grossly inefficient.

I really can see only 2 ways out of this dilemma:

• either all clients subscribing/publishing to a topic agree on the prefix map used for event payloads
• or CURIEs are not used at all in PubSub events

The latter could be a little more relaxed: a publisher may use (his own) prefix map, the server - knowing the publisher's prefix map - could reshrink the URIs contained, and dispatch with fully qualified URIs.

However, even then, the server needs to know the event payload structure to be able to identify the "strings" that really are URIs, and potentially need reshrinking.

We should make 3 conditions mandatory with this design question:

• URIs are just strings (dont introduce a "new type"), so a server unaware of the event payload structure cannot identify which elements of an event payload are URIs and which are just plain strings (containing whatever)
• server does not need to be aware of event payload structure
• server should be able to dispatch a message by serializing event to an octet sequence once, and send out that same octet string on all connected subscribers TCPs

Make Prefixes Peer-only

If we dropped the "reduce wire payload" requirement and made URIs on the wire always fully qualified (that is forbid CURIEs on wire), then things are much easier ..

There is a proposed WebSocket extension doing frame-based compression. But: either that is only able to compress within 1 frame, not maintaining compression state across frames, or it would maintain such state, but then the server could not prepare a compresses octet sequence once and send that out on multiple connections.

Incoming/Outgoing Prefix Maps

We should make that clean and symmetric.

Each peer (client and server) has 2 prefix maps for a session:

• incoming prefix map
• outgoing prefix map

From the server-side:

1. client establishes prefix "simple" = "http://example.com/simple#"
2. server receives PREFIX message and stores the definition in it's incoming prefix map
3. topic/rpc URIs in subsequent message from client are resolved using the incoming prefix map
4. the resolved URI is shrinked using the servers own map
5. server code can be written without knowledge which prefix definition the client used

From the client-side:

1. server establishes prefix "easy" = "http://example.com/simple#"
2. client receives PREFIX message and stores the definition in it's incoming prefix map
3. topic/rpc URIs in subsequent message from server are resolved using the incoming prefix map
4. the resolved URI is shrinked using the clients own map
5. client code can be written without knowledge which prefix definition the client used

[oberstet]

Probably we should make it simpler, instead of more complex:

• URIs on the wire are always fully qualified, never CURIEs
• the wire payload can be compressed, optionally, i.e. using transport compression like WS-deflate
• CURIEs can still be used -- purely peer side, implemented purely in peer library

[cboden]

If CURIEs are only used on peer side (client javascript?), what advantage is there defining a CURIE instead of just using a variable, if it's not going to be sent on the wire? Would it make sense to remove Prefix/CURIEs all together?

[oberstet]

Good point. I guess it would mostly be a matter of taste. There are multiple ways to make URI handling convenient - client side.

I really think this issue boils down to 2 sane options:

• always have full URIs on the wire
• have all clients agree on a common prefix map for CURIEs and have CURIEs on the wire

The first one is straight forward.

The second one raises the question on how that agreement happens.

[cboden]

I like simple. :)

[oberstet]

Yeah, me too. The concept of CURIEs seems somehow elegant, but the nitty gritty details in particular in the context of distributed PubSub (not so much RPC) are tricky.

I count that as 2 votes (you, me) to kick CURIEs from the wire protocol.

The Q of JS interface / URI convenience whatever is orthogonal .. can be done in AutobahnJS .. if at all.

[oberstet]

PREFIX message will be deprecated in WAMPv2.

[cboden]

👍

[heri16]

You guys are just removing a nifty feature of WAMP, making it appear lousier than STOMP over websocket.

[oberstet]

STOMP does not seem to provide builtin RPC features. The PREFIX message of WAMPv1 effectively only provides some adhoc, poor-man's compression. Using WebSocket compression, there seems to be no justification for PREFIX anymore.

[oberstet]

WAMPv2 has deprecated CURIEs altogether.