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

WIP: Event-based encoding API based on Data-E #1423

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

erights
Copy link
Contributor

@erights erights commented Dec 30, 2022

See http://www.erights.org/data/serial/jhu-paper/data-e-manual.html

@kriskowal , an unfortunate result of reminding me of Data-E ;)

@gibson042 , I don't know that I'll ever get it ready for review. But you may be interested anyway.

No longer staged on #1594 until it is on a more recent master

@erights erights self-assigned this Dec 30, 2022
@erights erights force-pushed the markm-data-jessie branch 4 times, most recently from 8fbd823 to 750e586 Compare January 15, 2023 07:10
@erights erights requested a review from dtribble March 26, 2023 03:04
@erights erights force-pushed the markm-data-jessie branch 5 times, most recently from 1633a1f to 15b3d4f Compare June 1, 2023 20:45
@erights erights removed the request for review from dtribble June 1, 2023 20:46
@erights erights changed the base branch from master to gibson-1349-encodepassable-escaping June 1, 2023 20:54
@erights erights changed the base branch from gibson-1349-encodepassable-escaping to master June 6, 2023 03:05
@erights erights force-pushed the markm-data-jessie branch 4 times, most recently from d70ff81 to 9f683f0 Compare July 8, 2023 00:41
@erights erights force-pushed the markm-data-jessie branch 2 times, most recently from 95ec395 to c6b75e3 Compare July 16, 2023 21:03
@erights erights force-pushed the markm-data-jessie branch 3 times, most recently from 810485d to 6e49597 Compare July 27, 2023 01:21
@erights erights force-pushed the markm-data-jessie branch 2 times, most recently from b249fc1 to a9f7a02 Compare August 6, 2023 19:48
Comment on lines +223 to +224
// copyRecord allows only string keys so this will
// work.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

copyRecord keys can be symbols now, right?

@gibson042 and I just talked about that recently, I think.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh... or is that Far object method names?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. Yes.

Cannot be copyRecord property names. Can be Far object method names.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though we discourage the latter until we see how receptive OCapN is to @kriskowal 's suggestions to no longer accept symbol method names per se. IOW, only string names transmitted as method names, where each side get to decide whether to translate it into a local string method name or a local symbol method name. Would require a bit of refactoring of abstraction levels, so method names have a special place, and so unlikely to be settled soon. Until then, the current symbols-also consensus stands. But we'd like to avoid unnecessarily entrenching that until this matter is settled.

@erights erights added the ocapn label Jun 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants