17 ms·

Using a filesync service such as Dropbox, you can sync state across multiple clients. We have a commercial user doing this. The single transit file won't scale

Using a filesync service such as Dropbox, you can sync state across multiple clients. We have a commercial user doing this. The single transit file won't scale however, so we've started working on a transaction log just as you said. Want to make sure it's pretty robust before deploying, however, as no data loss is the first priority! https://github.com/athensresearch/athens/pull/624 https://github.com/athensresearch/athens/pull/624 To your second answer, yes and yes. I write in the post: > As for how we will make money, most users, even technical ones who could self-host, don’t want to self-host (but they value that optionality and insurance against lock-in). They want a subscription SaaS, which will make features like backups, integrations, and collaboration much easier.

ryukafalz 6y ago
> The single transit file won't scale however, so we've started working on a transaction log just as you said. Would it be possible to deploy a web-based instance with the server handling storage and collaboration? If so, I might try my hand at packaging it for Sandstorm once that's available. Would make self-hosting Athens super easy for Sandstorm users.
- tangjeff0 6y ago
  This is my first time hearing of Sandstorm! Their page https://sandstorm.io/how-it-works https://sandstorm.io/how-it-works writes: > For example, when using Etherpad – a document editor app – on Sandstorm, every document lives in a separate container, isolated from the others. The front-end and database for that document live in the container. The container has a private filesystem for storage. JavaScript running in the user’s browser can talk only to the document container for which it was loaded, no others. All of this makes up a single “grain”. Right now Athens works directly with the filesystem (and therefore filesync services), not a REST-ful/HTTP server. I'm not sure how Sandstorm apps "talk to the document container." If they allow read/write access to the filesystem from the web app, it could work, but I'm not sure how Sandstorm works.
  - ryukafalz 6y ago
    Ah, yeah, it would need to work with an HTTP server for this to work well. Sandstorm has persistent storage on the server side - think server-side code running in a Docker container with client-side JS restricted to communicating with that container on the server. Client-side JS can't interact with the filesystem. I guess I was assuming that real-time collaboration would eventually involve some sort of synchronization server as a rendezvous point, in which case that would be the natural thing to run on the server side in Sandstorm. That may not be the route you're taking though!

ryukafalz 6y ago

> The single transit file won't scale however, so we've started working on a transaction log just as you said. Would it be possible to deploy a web-based instance with the server handling storage and collaboration? If so, I might try my hand at packaging it for Sandstorm once that's available. Would make self-hosting Athens super easy for Sandstorm users.

tangjeff0 6y ago
This is my first time hearing of Sandstorm! Their page https://sandstorm.io/how-it-works https://sandstorm.io/how-it-works writes: > For example, when using Etherpad – a document editor app – on Sandstorm, every document lives in a separate container, isolated from the others. The front-end and database for that document live in the container. The container has a private filesystem for storage. JavaScript running in the user’s browser can talk only to the document container for which it was loaded, no others. All of this makes up a single “grain”. Right now Athens works directly with the filesystem (and therefore filesync services), not a REST-ful/HTTP server. I'm not sure how Sandstorm apps "talk to the document container." If they allow read/write access to the filesystem from the web app, it could work, but I'm not sure how Sandstorm works.
- ryukafalz 6y ago
  Ah, yeah, it would need to work with an HTTP server for this to work well. Sandstorm has persistent storage on the server side - think server-side code running in a Docker container with client-side JS restricted to communicating with that container on the server. Client-side JS can't interact with the filesystem. I guess I was assuming that real-time collaboration would eventually involve some sort of synchronization server as a rendezvous point, in which case that would be the natural thing to run on the server side in Sandstorm. That may not be the route you're taking though!