widget-ify for integration into e.g. express about etherpad-lite HOT 10 CLOSED

Joe Cornelli started working on this, it was called GravPad afaik

from etherpad-lite.

I can see some intersection of what might be needed, but if this is GravPad:
http://news.kmi.open.ac.uk/11/1189
then I mean something different. Basically, I have a random node.js (or e.g. express.js) web application which does a bunch of stuff (storage/site/datamodel/etc), and has one (or several) datatype(s) that it wants to enable an etherpad widget for the body. So, you'd install the etherpad 'widget' in your node.js system, and after setting the proper URL routing, etc. up, it 'just works'

from etherpad-lite.

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?

from etherpad-lite.

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.

from etherpad-lite.

anyone wants to do this?

from etherpad-lite.

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.

from etherpad-lite.

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

from etherpad-lite.

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.

from etherpad-lite.

We're planning a API for ep-lite https://github.com/Pita/etherpad-lite/wiki/REST-API-Draft

from etherpad-lite.

awesome!

Some comments on the draft:

1. reconsider returning top-level json arrays for the list*() calls:
   http://stackoverflow.com/questions/3503102/what-are-top-level-json-arrays-and-why-are-they-a-security-risk
2. I presume it's planned, but it would be nice to say that the URL doesn't have to be at the root level (e.g. it could be available at /widget1/api/%FUNCTIONNAME% (when implemented elsewhere)

from etherpad-lite.