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

What would you need from a ShareLaTeX API? #1

Open
jpallen opened this issue Oct 7, 2015 · 1 comment
Open

What would you need from a ShareLaTeX API? #1

jpallen opened this issue Oct 7, 2015 · 1 comment

Comments

@jpallen
Copy link

jpallen commented Oct 7, 2015

Hello! I'm one of the co-founders of ShareLaTeX and this just popped up in my Google alert for new content on the web about 'sharelatex'. I've got to admire the hacker mentality here and the fact that it's well documented :)

We've recently started talking internally about creating an API for ShareLaTeX, since we've seen a few people put together ad-hoc scripts like this, and I think there's a lot of cool stuff that could be built on it. So my question for you is what would you need from a ShareLaTeX API in terms of end-points and functionality?

I guess this script would mainly need an official endpoint to download the project as a zip file? You mentioned read-write as a possibility, so what would you need there? Is there anything else that you might want to talk to ShareLaTeX about via a script, but haven't been able to because we don't have the endpoints?

@Jorl17
Copy link
Owner

Jorl17 commented Oct 8, 2015

Hi! Let me start by thanking you for ShareLaTeX. I've been using it for about four years and it has become my de-facto LaTeX editor.

I've got some suggestions for what you could expose via an API, although I understand that some of these might be an overkill to your business model and you might want to refrain from adding them:

  • Project download (e.g zip). Optionally with individual file downloads
  • File upload support. Individual files, or in bulk fashion (with a zip file). I'd easily make read-write a possibility with this.
  • Authentication support (some form of OAuth?). This would enable acting on private repositories

The next couple of features are something that this script does not need but I think could be useful:

  • "Compile & Download". It might be a good idea to just request that the final PDF is produced and downloaded. Or simply an option to recompile.
  • Project information. It would be a nice "plus" to be able to obtain some information regarding the project. I was mostly thinking about the title, but I'm sure there are other things, such as last date of change that might be useful to some people
  • History download. Really pushing it, but access to the project/file history, even if only available as part of a "premium-enabled API", could probably be great for applications to cook up interesting statistics and do all kinds of weird and funny things
  • Change notifications/Events. It's really not a very reasonable thing to think of in an API, but some form of push notification for changes or batches of changes, so that scripts and applications could react to them

(If some of this is already implemented and I just didn't see it, then sorry!)

Thanks for your interest and do tell if there's anything I can help with!

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

No branches or pull requests

2 participants