-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
widget-ify for integration into e.g. express #5
Comments
Joe Cornelli started working on this, it was called GravPad afaik |
I can see some intersection of what might be needed, but if this is GravPad: |
I'm totally with you on this point. Etherpad-lite should be a small framework that is very easy to implement in your own Express install. So no routing predefined in the framework itself. It should have some kind of api to get and set all relevant information. For example the timeline. Don't develop the timeline into etherpad-lite. Make a api function to get all the revs of the pad and to get the full text of that rev. Than developers can create a timeline by itself with their own designed user interface. Another example: the api should have a 'set and get latex/markdown from a pad'-function, so that other developers can write import/export functions for other formats. You could even get further by removing the edit-bar on the top of each pad and creating api-calls for that, but maybe that goes a little bit too far. Schuyler is this what you meant? |
yes, exactly! I think its ok if the etherpad routes assume after a certain base-url that the urls are the same (e.g. it might not be /foo and /bar but instead /etherpad/foo and /etherpad/bar. Also, it can't assume it's the only socket.io capturer/listener for the user. For that matter user apis should be abstracted. It's actually not too far from that already. the server.js is the default use, but with a little more abstraction on client/server side, it should be possible to connect etherpad to a larger service by doing e.g. a require('etherpad-lite/express') rather than running server.js. |
anyone wants to do this? |
I would like to do this, but got exams. I will start a wiki or pad with a todo list. Before we start doing this it should be clear what our outcome should be. A assumption of a certain base-url could be used in the communication between browser/etherpad-lite. But I think socket.io handles that pretty good without base-url. |
Just work with relative paths in the source code. We should remember that there is a world outside of node.js, where people may wanna use that too. The php front is still strong. Look at #13. It should be possible to change all path to relative paths with some sed commands |
You should see that separate. We will create a 'core' etherpad-lite. That could be this repository or another one. Than for people to use this with a php front we could create a example project. The example project will be more like this repository is now. Only be write upon the new api. -edit: your point of using relative paths is still relevant btw. |
We're planning a API for ep-lite https://github.com/Pita/etherpad-lite/wiki/REST-API-Draft |
awesome! Some comments on the draft:
|
Include sesson token verification in socket.io connection
Cookies persistence
No idea what I'm talking about yet, but instead of running etherpad as an app, it would be interesting to architect it as a widget (with both client/server side) parts that can be integrated into some node.js framework as an 'app' whatever that would mean.
I'm posting this as an issue, as a request, but also somewhat of a heads-up and an RFC if I start developing in that direction.
The text was updated successfully, but these errors were encountered: