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

Expose Java Operational Transform API #200

Open
ccotter opened this issue Jul 27, 2012 · 0 comments
Open

Expose Java Operational Transform API #200

ccotter opened this issue Jul 27, 2012 · 0 comments

Comments

@ccotter
Copy link
Member

ccotter commented Jul 27, 2012

The idea of moving the Java operational transform code into a separate repository and exposing the API has come up, so this issue will track further discussion and progress on a possible eventual implementation.

Current OT code status in coweb

There are two versions of the OT code in coweb: JavaScript and Java. The JavaScript version lives as a subdirectory in the coweb-javascript maven project in coweb-javascript/src/main/webapp/coweb/jsoe. The contents of this directory are only the raw OT JavaScript code.

The Java OT code exists as its own maven repository coweb-operationengine. The differences are important, and have good reason. It makes sense to have the Java OT code as a maven module, but typical JavaScript libraries do not exist as maven modules.

Options

If we did want to move the Java OT code out of coweb.git, there are two options. The following assumes moving the JavaScript OT code into a separate git repository coweb-jsoe.

  1. Have javascript and java OT in the same git repo (coweb-ot). This is nice because all OT code is together in a single project...however it makes maintaining coweb.git harder because no longer could we do the simple git submodule trick. With only coweb-jsoe, coweb.git has a single submodule in coweb/servers/java/coweb-javascript/src/main/webapp/coweb/jsoe. If both java and javascript OT are in a single git repo, then we could not have coweb.git use the OT code as a submodule due to the way coweb/servers/java is setup (we would have to manually pull the java and javascript sources in...).
  2. Have two new git repos: coweb-jsoe and coweb-javaoe. coweb.git includes both projects into itself as git submodules.

Pros:

  • All the OT code opencoweb has could live on its own as a standalone OT API (currently javascript and java).

Cons:

  • The first option above is nice that all OT code would be in a single git repo...but the impact on maintaining coweb is probably too great.
  • Option 2 makes life a little more difficult having to maintain two new separate repos that do very similar things (as opposed to just the one coweb-jsoe). Changes to the OT engine or the exposed API means having to track two separate git repos.
  • If we have javascript and java versions of an exposed OT API, it means more code to maintain down the road.
@ccotter ccotter closed this as completed Aug 22, 2012
@ccotter ccotter reopened this Aug 22, 2012
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

1 participant