Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Verbose record labels while we figure things out, enums or short labels later #4

Open
cwebber opened this issue Apr 16, 2021 · 2 comments

Comments

@cwebber
Copy link
Contributor

cwebber commented Apr 16, 2021

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.

@zarutian
Copy link

zarutian commented May 5, 2021

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

@tsyesika
Copy link
Contributor

tsyesika commented Jul 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants