You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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!
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?
The text was updated successfully, but these errors were encountered: