Drophost | Hacker News Reader

Drophost

5 pointselisk5 comments

I'm starting to build a small personal project to use Dropbox as a simple interface to manage/create a website.

The basic idea is that the user uploads a script to his hosting server, logins with his dropbox credentials, at which point a new custom folder is created in the dropbox directory which represents the htdocs of the host.

From this point on files are basically either PHP, HTML, or Markdown files, and any changes to the local files will be reflected right away on the host where the script was installed.

It's intended to be a sort of replacement to Drupal/Wordpress and other CMS software designed for developers and hackers - I don't want to be bothered with installing various scripts, running through a UI whenever I want to upload a file or a new post in my blog/site, and I'd prefer to simply manage my site as if it was a local file system, no databases (well, maybe a little SQLite), a basic caching system (after parsing the files, we want to store them in some form that will not rape the server every time a new visitor arrives), and something that can be easily extendable.

>I don't want to be bothered with installing various scripts, running through a UI whenever I want to upload a file or a new post in my blog/site, and I'd prefer to simply manage my site as if it was a local file system, no databases (well, maybe a little SQLite), a basic caching system (after parsing the files, we want to store them in some form that will not rape the server every time a new visitor arrives), and something that can be easily extendable.

You're going to fall between two stools. If you want something to be extendable, people are going to have to have a way to install their extension scripts; if you don't give them a way to do it, they'll copy and paste with all the problems that entails. "manage my site as if it was a local file system" is unpleasant for anything but the simplest of sites; usually you'll want to test locally before deploying, and restore changes from history - at which point, heroku is about as simple as possible.

Either make a super-simple system - no extensibility, no caching, no sqlite - or make something that can compete with heroku.

Hmm...I have a Linux server out there, serving web pages and also running a Dropbox CLI client. My laptop runs the usual Dropbox client. The two computers share a folder between them; this shared folder is also the web root for a site on the server.

So, any changes I make at my local computer are synced to the server via Dropbox. No logins (beyond the initial set-up), no manual uploading; just save the files locally and they automagically appear on the server.

Is that what you had in mind? (this is the link for the command-line client: https://www.dropbox.com/install?os=lnx )

Yes. That's the basic idea that lead me to the above post, but from what I hear (no benchmarks or test though) the dropbox cli is too expensive on the resources.

And even if that's a non-issue, what I'm talking about is a bit more robust solution - providing the user with some basic tools (like doing markdown/haml pages) right off the bat without any additional hacking.

On top of that, installing dropbox-cli as simple as it might be, is not simple enough and requires access to the shell (that not everyone might have), running a daemon, and it's not super secure (you need to store your root password, no?). My idea is that whenever you install a drophost, you get a new folder in your dropbox with the name of your host (i.e. /dropbox/drophost/mydomain.com/) which is simple to navigate and maintain multiple sites.

Hmm...the host in question is a tiny VM, and the resource usage by dropboxd is negligible (<10 MB of memory, CPU usage ~0.00, in my case); if you don't believe in hearsay, try it out for yourself ;) The daemon runs completely user-side - there's no need to do anything as root, let alone store passwords (you do need to store the Dropbox auth token, so that the daemon can re-login into DB; this is more secure than storing passwords, and doesn't give you access from anywhere else). The daemon only requires shell access on install - after that, it's a completely hands-off solution.

Still not sure how you'd imagine the integration - the markdown pages would be processed into HTML on the server?

We actually have this exact set-up for our wiki. Instead of mediawiki we just have a dropbox feeding into a in-house built markdown parser/compiler that generates our wiki.

Reply on news.ycombinator.com