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

Would it make sense to define a "wire protocol" to make it possible to interface with non-elixir datasets? #1

Open
jeregrine opened this issue Jun 17, 2015 · 3 comments

Comments

@jeregrine
Copy link

This would be super handy to use with syncing clients and the server. Do you think it makes sense to define a protocol? I know swarmjs has one.

Or do you think it's best to just let users define it?

@edescourtis
Copy link

+1 that

@asonge
Copy link
Owner

asonge commented Jun 17, 2015

I'm not sure what that would look like. I've been thinking about this and the common use cases for client-side CRDT's and how to evaluate the security implications of merging values from users with different permissions. The only thing I can come up with is that clients that aren't trusted need to use ops-based CRDT's. Doing this in a state-based way seems a lot more difficult and prone to bugs. I'd only use this state-based stuff for maintaining trusted/server state and syncing servers.

When it comes to a javascript companion library that covers most use-cases (and defines a set of json datastructures), it's definitely on my to-do list. My day job should start slowing down soon, so this repo is about to get active again. I think once you have that, it should be possible to write stuff in other languages that obeys the basic json contract.

As far as a protocol goes, this stuff can be made fairly rigorous because actions are idempotent. A complicated protocol doesn't seem to be needed.

@jeregrine
Copy link
Author

Just like defining and sticking to a protocol even if its simple can go a long way.

On Wed, Jun 17, 2015 at 5:03 PM, Alexander Songe notifications@github.com
wrote:

I'm not sure what that would look like. I've been thinking about this and the common use cases for client-side CRDT's and how to evaluate the security implications of merging values from users with different permissions. The only thing I can come up with is that clients that aren't trusted need to use ops-based CRDT's. Doing this in a state-based way seems a lot more difficult and prone to bugs. I'd only use this state-based stuff for maintaining trusted/server state and syncing servers.
When it comes to a javascript companion library that covers most use-cases (and defines a set of json datastructures), it's definitely on my to-do list. My day job should start slowing down soon, so this repo is about to get active again. I think once you have that, it should be possible to write stuff in other languages that obeys the basic json contract.

As far as a protocol goes, this stuff can be made fairly rigorous because actions are idempotent. A complicated protocol doesn't seem to be needed.

Reply to this email directly or view it on GitHub:
#1 (comment)

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