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

Offline reconcilliation #1

Open
gerardwebb opened this issue Jun 18, 2020 · 4 comments
Open

Offline reconcilliation #1

gerardwebb opened this issue Jun 18, 2020 · 4 comments

Comments

@gerardwebb
Copy link

gerardwebb commented Jun 18, 2020

I would like to help as i code golang and love what Gio gui framework is doing.

Currently i use flutter and golang together BTW, however i see awesomeness in the Gio approach

The Sprout spec is interesting. For me i woudl have thought a Kappa approach with CRDT woudl have been more reusable, but i have not really dived into running the relay, and CLi yet to see how it handles off line edits, which is always the sticky part :)

@gerardwebb gerardwebb changed the title CRDT Offline reconcilliation Jun 18, 2020
@whereswaldon
Copy link
Member

Hi @gerardwebb! Thanks for your interest, and welcome to our community!

Currently i use flutter and golang together BTW, however i see awesomeness in the Gio approach

I've done some research on Flutter and Go myself, but having to go through CGO to do any UI changes was a real pain. If you have any resources on that, I'd be very interested to see them!

The Sprout spec is interesting. For me i woudl have thought a Kappa approach with CRDT woudl have been more reusable, but i have not really dived into running the relay

Sprout itself is only in its first iteration. It's the simplest protocol that we could devise in order to ship updates around. However, I'd love to discuss other options.

, and CLi yet to see how it handles off line edits, which is always the sticky part :)

Arbor doesn't support "edits" in a conventional sense. The forest is immutable. Editing a message (not yet implemented) will take the form of creating a child node with special metadata indicating that it is a patch applied to its parent.

Could you elaborate on the more reusable approach that you're envisioning?

Also, FYI, we usually do this kind of stuff on our sourcehut issue tracker, which handles issues for all of the repos in the project. I just haven't gotten around to setting up the GitHub action that we use to automatically redirect issues there. Happy to have this conversation here, but that's probably a better place to open future issues.

@joe-getcouragenow
Copy link

Hi @gerardwebb! Thanks for your interest, and welcome to our community!

Well thanks for this project. Am loving gio !!

Currently i use flutter and golang together BTW, however i see awesomeness in the Gio approach

I've done some research on Flutter and Go myself, but having to go through CGO to do any UI changes was a real pain. If you have any resources on that, I'd be very interested to see them!

Starting to agree. I like the GIO approach of "close to the GPU"..

The Sprout spec is interesting. For me i woudl have thought a Kappa approach with CRDT woudl have been more reusable, but i have not really dived into running the relay

Sprout itself is only in its first iteration. It's the simplest protocol that we could devise in order to ship updates around. However, I'd love to discuss other options.

Yeah i got pretty lost in the code in terms of trying to understand the logic.

I have been playing around with GRPC / Protobufs working with WASM in the browser. Mostly because i need to build more apps tan just chat and so a strongly typed contract can make things more sane for devs.

I have been looking into how to get the equivalent of GRPC-Web but with no envoy, and golang server and GIO client.

This one works. I just need to test compiling with GIO
https://github.com/elliotpeele/golang-wasm-example

This one i am not sure yet: https://github.com/dennwc/dom/tree/master/examples/grpc-over-ws

Its my own bias i know. I like code gen so that refactoring is nice.

, and CLi yet to see how it handles off line edits, which is always the sticky part :)

Arbor doesn't support "edits" in a conventional sense. The forest is immutable. Editing a message (not yet implemented) will take the form of creating a child node with special metadata indicating that it is a patch applied to its parent.

Ok that looks pretty simple...

Could you elaborate on the more reusable approach that you're envisioning?

I dont have enough understanding of Forest yet to comment.

There are two golang ones out there i have seen so far.
CRDT based: https://github.com/yorkie-team/yorkie

Merkel Dag Diff based: https://github.com/rocicorp/diff-server

  • uses the noms lib.
  • I have not gotten a chance to dig into it yet.

Also, FYI, we usually do this kind of stuff on our sourcehut issue tracker, which handles issues for all of the repos in the project. I just haven't gotten around to setting up the GitHub action that we use to automatically redirect issues there. Happy to have this conversation here, but that's probably a better place to open future issues.

@whereswaldon
Copy link
Member

Well I'm happy to consult on gio work if you ever have questions, though the gioui slack channel or arbor might be a better place for such discussions!

I have little experience with grpc and protobuf, so I'm afraid that I can't be much help with that part of it.

You probably already have websockets working, but if not there's this: https://git.sr.ht/~whereswaldon/gio-wasm-ws

I wrote it a few months back, so some of the gio code won't work with the latest API. The principles should still apply though.

I think you're thinking in terms of a much more complex collaborative editing kind of experience than what arbor actually does. Is that what you're looking to build? A collaborative editor in the browser?

@joe-getcouragenow
Copy link

Well I'm happy to consult on gio work if you ever have questions, though the gioui slack channel or arbor might be a better place for such discussions!

Thanks for the offer about consulting. Its something i would be open to actually.
I have been doing a fair bit of due diligence lately as we hit the wall with Flutter GUI and and golang backend because of the dual coding languages, and so GIO provides some advantages.

Yeah i am active in the GIO a sourcehut. I did not even know there was a slack channel :) How did i miss that !

I have little experience with grpc and protobuf, so I'm afraid that I can't be much help with that part of it.

Me too :)

You probably already have websockets working, but if not there's this: https://git.sr.ht/~whereswaldon/gio-wasm-ws

I wrote it a few months back, so some of the gio code won't work with the latest API. The principles should still apply though.

Looks pretty clean. Will give it a whirl..
If we start to use gio, instead of flutter then GRPC becomes close to useless for us. GRPC is really to help with one language talking to another. WithGolang on both sides you can share an object both sides and your off to the races.
Also then you can use QUIC and WebRTC and Websockets. This is where we are much more interested. I am pretty sure QUIC Web Transport will become pretty active soon and so we use WebRTC now for things and that sets us up to use QUIC later as the patterns are almost identical.

I think you're thinking in terms of a much more complex collaborative editing kind of experience than what arbor actually does. Is that what you're looking to build? A collaborative editor in the browser?

YES spot on. Its Gsuite / Telegram combined for Web, Desktop, Mobile, and pine64 hardware.

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