3 ms·

Show HN: An Open Source Documentation Server

12 points by y4m4b4 10y ago

stephenr 10y ago
Can someone explain the key differences between this and say gollum, which doesn't need postgres installed just to serve rendered markdown documents?
deekoder 10y ago
Doctor is way simpler. You create categories or headings. Copy paste links to your documentation files (MD) from github.com into Doctor's Dashboard. There is no creating, editing doc content from within Doctor. It looks to me like Gollum allows the user to use a wiki like interface to create and commit docs in github. Gollum also seems to allow a variety of formats other than markdown when the user is creating documentation through their server. Doctor sticks to aggregating, categorizing and presentation. Postgres is used to manage document links and categories and not content itself. Doctor lets github do all the heavy lifting on document creating & editing and versioning.
- stephenr 10y ago
  It seems somewhat ironic that a "simpler" tool that lets something else "do the heavy lifting", needs a Postgres database, whereas gollum just uses the file system (holding a git repo)
  - y4m4b4 10y ago
    Gollum is a great project and it is really nice to see great supportive community around it. Doctor only solves a niche problem of serving existing content, aggregating it and managing it using github.com directly. Postgres is generally for the CRUD in grouping, aggregating/associating and customization. Do you have any better suggestion? Feel free to play with it and give us your feedback.
    - stephenr 10y ago
      Serving markdown content isn't a niche, within the set of what gollum does. I honestly don't understand what "aggregating/associating" you're talking about, that isn't possible in a regular markdown wiki (eg using gollum, but also several other md based wiki tools). As for suggestions - if your tool is specifically aiming to be lightweight, use a lightweight db, like SQLite.
      - y4m4b4 10y ago
        Great to know, we explored sqlite didn't serve our purpose earlier. Feel free to open a bug and we will evaluate it.

12 points by y4m4b4 10y ago

Can someone explain the key differences between this and say gollum, which doesn't need postgres installed just to serve rendered markdown documents?

deekoder 10y ago

Doctor is way simpler. You create categories or headings. Copy paste links to your documentation files (MD) from github.com into Doctor's Dashboard. There is no creating, editing doc content from within Doctor. It looks to me like Gollum allows the user to use a wiki like interface to create and commit docs in github. Gollum also seems to allow a variety of formats other than markdown when the user is creating documentation through their server. Doctor sticks to aggregating, categorizing and presentation. Postgres is used to manage document links and categories and not content itself. Doctor lets github do all the heavy lifting on document creating & editing and versioning.

stephenr 10y ago
It seems somewhat ironic that a "simpler" tool that lets something else "do the heavy lifting", needs a Postgres database, whereas gollum just uses the file system (holding a git repo)
- y4m4b4 10y ago
  Gollum is a great project and it is really nice to see great supportive community around it. Doctor only solves a niche problem of serving existing content, aggregating it and managing it using github.com directly. Postgres is generally for the CRUD in grouping, aggregating/associating and customization. Do you have any better suggestion? Feel free to play with it and give us your feedback.
  - stephenr 10y ago
    Serving markdown content isn't a niche, within the set of what gollum does. I honestly don't understand what "aggregating/associating" you're talking about, that isn't possible in a regular markdown wiki (eg using gollum, but also several other md based wiki tools). As for suggestions - if your tool is specifically aiming to be lightweight, use a lightweight db, like SQLite.
    - y4m4b4 10y ago
      Great to know, we explored sqlite didn't serve our purpose earlier. Feel free to open a bug and we will evaluate it.