Feature list / prioritization / milestones

funkyeah commented 8 years ago

Writing down a list of possible features. Feel free to edit this post directly. We can prioritize and breakdown as needed.

Proof of Concept

[x] ability to collaboratively edit a single doc with multiple users (see #4)
- [x] integrate rocketchat streamer
- [x] single Authority, single server
- [x] AuthorityManager, create/manage multiple Authorities on single server
- [x] client has API to attach ProseMirror instance to DOM element, which hooks up its collab module to the server authority

`Public Beta` Milestone

[x] edit multiple docs simultaneously (if client API just attaches to one DOM el and connects with back end authority, this shouldn't take any extra effort)
[x] permissions integration hook(s) / setup? (see #9)
[ ] a read-only mode that doesn't set up an authority for collaborative editing (see #15)
- [ ] inject-data for document on connect first
- [ ] prose-mirror readonly - or html read-only? https://discuss.prosemirror.net/t/what-does-a-read-only-editor-even-mean/221
- [ ] do we push the data into a collection locally? probably don't have to, unless user wants to query that data for some reason. we could add option to put it in a collection if specified
[ ] ability to restore document state from previous snapshots (see #14)
[x] schedule automated doc snapshots while doc is open (see #12)
[x] automatically save a snapshot when a doc is closed (no more users editing it), and delete the Authority from memory (see #18)
[x] reasonable horizontal scalability
- [x] N number of authorities, with service discovery to get IP of server hosting an Authority (see #8)
- [x] Authority is removed from registry if it goes offline (see #8)
[x] ability to group documents via "groupId", which are all guaranteed to be hosted on the same authority server (see #20)
- [x] only broadcast events to necessary clients by splitting up Streamer events into namespaces/channels (see #28)
[ ] integration and e2e tests, with automated builds (see #29)
[ ] block some Meteor Methods from client access (see #34)
[ ] Invalidate doc authentication (see #35)

`1.0` Milestone

[ ] migrate existing sessions of a server before it's shut down for rolling deployments (see #23)
[ ] integration with ProseMirror is through a PM plugin (see #11)
[ ] update to latest Meteor and ProseMirror (see #27)

Extra Features

[ ] diffing of previous snapshots
[ ] cursor for each editor

ejfrancis commented 8 years ago

Looks good! I just split them up into sections. I'm sure there's more we could add to Extra Features down the road, but Core Features are all things we probably need for a real release. I'm comfortable working on the horizontal scaling (service discovery) so I can take that on if that's alright.

@archonic you still up for helping with some of this work? We're almost at the point where we can start writing up individual issues for each piece.

ejfrancis commented 8 years ago

Btw we should probably agree on how the API looks from a user standpoint. This is what I'm imagining right now, let me know any feedback or what you've got in your heads

Say I have a view like this

<body>
  <div id="editor-target">
  </div>
</body>

I'd really love to be able to just do

ProseMeteor.openDoc({ 
   docId: 'someDocId',
   domEl: document.getElemenyById('editor-target')
});

Ideally that's it (or something really similar to it), you don't need any server-specific app code. Since this is an isomorphic package the client can call the appropriate server methods that we've created, if a docId was provied then find the hosting authority's IP, if no docId was provided then request to have a new authority created, and hook everything up. I'm not entirely sure how this would work end-to-end, especially with things like permissions/security since I've never built a proper isomorphic Meteor package, but it would be so cool if it was that easy and would definitely align with the Meteor mindset. I'll have to think about it a bit to see if it's feasible.

funkyeah commented 8 years ago

I do like keeping it simple. I was thinking that on the client we would just be creating our own Prosemirror module. The user would create/open a prosemirror instance like normal but with prosemeteor option that we add set to enabled and/or whatever options it would need:

import { Prosemirror } from 'meteor/prosemeteor:prosemirror'

let editor = new Prosemirror({
  place: document.querySelector(".full"),
  menuBar: true,
  autoInput: true,
  tooltipMenu: {selectedBlockMenu: true},
  doc: "Placeholder content",
  docFormat: "html"
  prosemeteor : true
});

In someways that might be thinner and more flexible. On the other hand if we don't wrap it we would need to be more explicit about what standard modules and options the prosemeteor package actually supports. Can you spot any prosemirror module options outside of the ones added by the collab module that would cause problems or not be trivially supported?

Thoughts on other client side configuration options that would be specific to the proseMeteor module?

Codewise, so far I've just cleaned up the package to be more ES6 and guide matching and added meteor-streamer. Feeling better about hacking away though.

ejfrancis commented 8 years ago

Yeah I think you're right, keeping ProseMirror outside the package and just attaching ProseMeteor to it is probably better so that we're not locked into a single ProseMirror version.

funkyeah commented 8 years ago

Early on while ProseMirror is still under rapid change I think it might be OK to be locked into a single ProseMirror version, but long-term it seems that declaring it a peer-dependency is probably the way to go.

What do you think about client and server API/config options?

ejfrancis commented 8 years ago

What do you think about client and server API/config options?

well looking over the feature list it looks like at least these

read-only mode
snapshot enabled/disabled
snapshot interval if enabled
perhaps an option to disable collab altogether? So the user could still use the same ProseMeteor api to retrieve previous saves, load a doc onto a page, and save snapshots, it just wouldn't hook up the collab module and would save snapshots right from the user's local state

We'll need some sort of permissions options, but I'm not sure how we'll do that. I imagine they should probably be set on a per-document basis (only users X,Y,Z, or users of group A, can edit). On that note perhaps we should make two sets of permissions, those who can edit a doc, and those who can view it. The Meteor guide recommends the defacto user roles package alanning:roles package for permissions, maybe we could use that?

funkyeah commented 8 years ago

for your third bullet above:

client has API to attach ProseMirror instance to DOM element, which hooks up its collab module to the server authority

I wrote some thoughts in the code on how this could look

As I was suggesting earlier maybe prosemeteor is partially a plugin for prosemirror. When an integrator initializes an instance they do so by including our plugin in the options list. That option can be passed either A) an id of the doc in the snapshot collection or B) a selector that matches a DOM element or elements that have PM doc ids in their attributes somehow. Thoughts?

If you are going to be banging on the code this week I'll stay out of the way for the most part. Let me know if there is something you want me to work on and/or look at.

ejfrancis commented 8 years ago

That would be nice. I don't know much about how ProseMirror plugins work, I'll have to read up on them. Here's the wiki on plugins for reference

funkyeah commented 8 years ago

As far as I understood... and I think the wiki confirms this... there isn't a whole lot to being a prose-mirror plugin since its all ES2015. Registering/defining the prosemirror option is really the only plugin specific, and that just provides a clean way of having prosemirror instantiate the prosemeteor code rather than having the user create a prosemirror instance and then somehow pass that prosemirror instance into a prosemeteor wrapping function. Theres a good chance I dont know what I am talking about though.

On Thu, May 19, 2016 at 11:40 AM, Evan Francis notifications@github.com wrote:

That would be nice. I don't know much about how ProseMirror plugins work, I'll have to read up on them. Here's the wiki on plugins https://github.com/ProseMirror/prosemirror/wiki/Plugins for reference

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/prosemeteor/prosemirror/issues/3#issuecomment-220382138

ejfrancis commented 8 years ago

Just thinking out loud about how to make this a plugin. Right now on the server's authority we have to be able to import the Step class and defaultSchema from ProseMirrorin order to be able to create a doc and apply steps to it on the server.

That's possible right now because we're just importing it right from ProseMirror. But if we make it a plugin, I think we'd have to have the user pass in the Step and defaultSchema objects into ProseMeteor somehow so that we could use them without importing them directly from ProseMirror.

funkyeah commented 8 years ago

I think it's perfectly legitimate to declare Prosemirror a peer dependency and make the end user do an npm install or meteor npm install of the prosemirror npm package before they can use Prosemeteor. This is what Meteor reccomends when installing React. Then Prosemeteor can just import the necessary prosemirror objects the standard way.

When I think "plugin" I am only thinking of how the user instantiates Prosemeteor on the client side. On the server side its predominately Prosemeteor code so I don't think we really have to pretend to be a plugin there.

e.g.

  let editor = new ProseMeteorEditor({
    docId: 'proofOfConceptDocId',
    proseMirrorOptions: {
      place: document.querySelector(".full"),
      menuBar: true,
      autoInput: true,
      tooltipMenu: {selectedBlockMenu: true}
    }
  });

vs.

let editor = new Prosemirror({
   place: document.querySelector(".full"),
   menuBar: true,
   autoInput: true,
   tooltipMenu: {selectedBlockMenu: true},
   doc: pmDoc,
   docFormat: "json",
   prosemeteor: {
        id: collabDocId 
   }
});

ejfrancis commented 8 years ago

I didn't even think of just having a peer dependency and still importing it, good call! then I guess it shouldn't be much of an issue at all

ejfrancis commented 8 years ago

Here's another feature I've been thinking about: If I know that I'll have say 5-10 ProseMirror instances on the same page, it'd probably be better to make sure they all end up with Authorities on the same server since web browsers have a limit to the number of concurrent connections and latency may be different between them. Perhaps we could have the option of associating a doc with a "docGroupId" or something of the sort, and when creating an authority we'd make sure every doc with that "docGroupId" would end up living on the same server. What do you think?

archonic commented 8 years ago

@ejfrancis I'm still alive, just been very busy getting married 😄. Very willing to help out and I anticipate being more available in July.

ejfrancis commented 8 years ago

@archonic congrats! No worries, but any help you wanna pitch in is definitely appreciated. I'm sure we can write up some more issues and assign them to you. Try out the demo when you've got a chance, it's pretty cool 👍

ejfrancis commented 8 years ago

I've just added migrate existing sessions of a server before it's shut down for rolling deployments to the list per @ellery44's suggestion. That one should be interesting to implement.

ejfrancis commented 7 years ago

I've added two milestones to the project and tagged them in individual issues, Public Beta and 1.0

prosemeteor / prosemirror