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

Inline media assets (images, etc.) #29

Open
thomasmaclean opened this issue Nov 3, 2016 · 5 comments
Open

Inline media assets (images, etc.) #29

thomasmaclean opened this issue Nov 3, 2016 · 5 comments

Comments

@thomasmaclean
Copy link

I'd like to contribute with the ability to include inline assets (such as images, youtube videos, etc). Is the level of effort on this unrealistically high? I see that the data model focuses on individuals characters syncing over Swarm, but has the door been left open for non-text elements?

@rocketraman
Copy link
Contributor

Thanks for your interest!

The data store backend of Ritzy that allows real-time collaboration -- Swarm -- is pretty fragile, and not really amenable to making these types of changes easily. And the Swarm project, while it showed lots of promise, isn't really getting anywhere close to an enterprise-ready state, as far as I can tell.

What I'd like to see happen is:

a) the specifics of the backend becomes abstracted away from the frontend editor bits (the surface rendering and input handling),

b) a new backend (or backends) can be implemented (perhaps CouchDB+PouchDB would work well?), and

c) the frontend starts evolving features such as this one, using the new more capable backend abstraction.

I know you want to tackle (c) but I believe (a) and (b) really need to be tackled first. Any interest in doing so?

@thomasmaclean
Copy link
Author

At this point no. Thank you for the quick reply though! It's helpful to get confirmation on what we had already more or less suspected.

We've started moving in the direction of a simple LWW Redux/Socket.io system with field-level locking (so editors can edit a page with many fields, while the field they're working on is locked). In that case, Draft.js providing a block-level editor makes the most sense.

@Tamriel
Copy link

Tamriel commented Nov 8, 2016

a new backend can be implemented

What are the shortcomings of Swarm? Grishchenko is working on an updated protocol for Swarm.
Wouldn't it be easier to help him finishing Swarm?

@ztl8702
Copy link

ztl8702 commented Nov 14, 2016

I am interested, although I don't have much knowledge about OT.

In terms of a), is it something similar to this: https://github.com/firebase/firepad/blob/master/lib/firebase-adapter.js ? (The Firebase adapter for firepad; although they don't seem to have another backend other than Firebase.)

@rocketraman
Copy link
Contributor

@ztl8702 Thanks for your interest! terms of a), is it something similar to this: https://github.com/firebase/firepad/blob/master/lib/firebase-adapter.js ? (The Firebase adapter for firepad; although they don't seem to have another backend other than Firebase.)

I'm not familiar with firepad / firebase, but in general, Ritzy uses CRDT rather than OT, and everything is character-based i.e. the CRDT data structure maintained by Ritzy is the CRDT character array. Changes to this array, both local and remote, are reflected immediately on the editing surface via event notifications.

Currently, there is a pretty tight coupling between the editor surface and the CRDT data structure. I haven't thought too much about how to abstract this, nor about how to support inline assets within the same data structure. Suggestions welcome.

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

No branches or pull requests

4 participants