You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, Goblins' CapTP representation (see also #3) uses very verbose records: they look like <'op:deliver-only ...>; every record label is a full stringy-symbol. This is not desirable in the final version, but it makes it very easy to reason about the protocol now. It is easy to type out a description of the protocol that is moderately human readable in the textual representation of preserves.
However, when we ship, we probably want to enum'ify this... replace all of these with short bytes, strings, symbols or integers... no more than an octet in length each. But I suggest we do this later in the design, so we can keep our brains well wrapped around things.
The text was updated successfully, but these errors were encountered:
mulling note I have on this:
have short or numerical symbols like 42s
use a 'meta' syrup record of the form <14'meta:symAssign42+10'op:deliver> which, in this example, assigbs short symbol 42s to symbol op:deliver
these meta:symAssign would be sent at the start of a connection and apply
to the syrup symbols sent on that connection in same direction as the meta:symAssign were sent
this enables economy of compression while not having to specify outside the connection which short symbol corrisponds to which stringy symbol
We discussed this in July 2024's meeting. We seemed to have general agreement the goals of the issue is good, but we should discuss it more, possibly adding this to the agenda in a future meeting.
Right now, Goblins' CapTP representation (see also #3) uses very verbose records: they look like
<'op:deliver-only ...>
; every record label is a full stringy-symbol. This is not desirable in the final version, but it makes it very easy to reason about the protocol now. It is easy to type out a description of the protocol that is moderately human readable in the textual representation of preserves.However, when we ship, we probably want to enum'ify this... replace all of these with short bytes, strings, symbols or integers... no more than an octet in length each. But I suggest we do this later in the design, so we can keep our brains well wrapped around things.
The text was updated successfully, but these errors were encountered: