3 ms·

You can run a community of sorts, but the feature list will be sparse. The only viable system sans-database that comes to mind is plain-text. I'm a member of a

by ejr 12y ago

You can run a community of sorts, but the feature list will be sparse. The only viable system sans-database that comes to mind is plain-text. I'm a member of a forum that had an old system in the beginning that used plain text "database" for a very long time. Performance was fairly reasonable at 5000 visitors per day, if the daily hit counter was to be trusted. They since moved it to SQLite, which is very reliable in its own right, and now it's Postgres. It was only now that we got searching as a "feature". The system was written originally in PHP 4.x, but they did move it to 5.x. I'm not sure what version they use now. I do know they were running ancient hardware and was up solely due to the charity of the admin. I think there was an index file that stores new topic summaries, as there was no field for titles, when they were created. They used microtime() as the ID, but the topics were stored by splitting it to 3 digit directories. Seconds as 1234567890 and decimal 0.12345618 were combined to create /123/456/789/012/345618.html There's no registration system or other way to identify the user so I believe the posts were separated by some kind of entry separator in a single file. I think the pagination system created an array of sequential IDs and checked to see if files existed in those directories. There were no numbered links for pagination, only next/previous and if you reached the end, the next page would be blank. There's no reason you should ever get laughed at for being curious.

escapologybb 12y ago
Thanks, I appreciate the nice answer but it's amazing how often newbies get laughed at for being curious! Glad it hasn't happened today :-) So on to your answer, I'm going to be running this community at way less than 5000 visitors per day! So from what I understand, the site was run using PHP and every time somebody made a new entry a new file was created on disk with a reference to that file in the main index page. With the name of the file was based on the time it was written to disk, with some checking to make sure to avoid files with duplicate names. I assume the main index file was the front page of the site? Have I got that right? And if so, where do you think I should take my studying to set something like this up. I mean, are there any frameworks that you know of like Jekyll for instance or would I need to learn PHP before I could set it up?
- d33n 12y ago
  There are a lot of open source products you can use, I would advise start at http://en.wikipedia.org/wiki/List_of_content_management_systems http://en.wikipedia.org/wiki/List_of_content_management_syst... to find a Wiki/CMS in the language you like most, with a flat-file database. Then look for plugins/extensions that provide the community features you need.
- ejr 12y ago
  There are lots of samples for PHP, but you don't need to study that. As d33n suggests, there are examples that already use flat files as a database and you can browse Github for code examples. Our forum was setup so that one thread = one HTML file. Any new replies to the thread were appended to the bottom of the file right before the footer. The added benefit of this is that it was very quick to read new posts as there was no processing taking place after the post is created. Ex: If a new thread is being created, it will generate an ID, say 140585637400000000. Now this gets translated into a path : /140/585/637/400/000000.html and a file is created there. The body of the new thread is added to the HTML file. Any subsequent replies are added to that same file right below the previous one. So when a visitor requests example.com/topic/140585637400000000, the script takes the last part, turns into a file path, adds a template - which has the reply form with that ID - and sends it to the user. No additional processing needed. When a new reply is made, the script builds the path again and adds it to the bottom of the same HTML file. And so on... I think your biggest hurdle is the initial planning. Try to carefully plan this out as much as you can, but obviously you won't know what future circumstances will bring. If you build it in such a way so that the storage mechanism doesn't need to change much or at all, you should be most of the way there. Edit: Maybe I can convince the admin to publish some of the source. You're not the only one to be interested in something similar and I think there's a real demand for lo-fi community software.

by ejr 12y ago

escapologybb 12y ago

Thanks, I appreciate the nice answer but it's amazing how often newbies get laughed at for being curious! Glad it hasn't happened today :-) So on to your answer, I'm going to be running this community at way less than 5000 visitors per day! So from what I understand, the site was run using PHP and every time somebody made a new entry a new file was created on disk with a reference to that file in the main index page. With the name of the file was based on the time it was written to disk, with some checking to make sure to avoid files with duplicate names. I assume the main index file was the front page of the site? Have I got that right? And if so, where do you think I should take my studying to set something like this up. I mean, are there any frameworks that you know of like Jekyll for instance or would I need to learn PHP before I could set it up?

d33n 12y ago
There are a lot of open source products you can use, I would advise start at http://en.wikipedia.org/wiki/List_of_content_management_systems http://en.wikipedia.org/wiki/List_of_content_management_syst... to find a Wiki/CMS in the language you like most, with a flat-file database. Then look for plugins/extensions that provide the community features you need.
ejr 12y ago
There are lots of samples for PHP, but you don't need to study that. As d33n suggests, there are examples that already use flat files as a database and you can browse Github for code examples. Our forum was setup so that one thread = one HTML file. Any new replies to the thread were appended to the bottom of the file right before the footer. The added benefit of this is that it was very quick to read new posts as there was no processing taking place after the post is created. Ex: If a new thread is being created, it will generate an ID, say 140585637400000000. Now this gets translated into a path : /140/585/637/400/000000.html and a file is created there. The body of the new thread is added to the HTML file. Any subsequent replies are added to that same file right below the previous one. So when a visitor requests example.com/topic/140585637400000000, the script takes the last part, turns into a file path, adds a template - which has the reply form with that ID - and sends it to the user. No additional processing needed. When a new reply is made, the script builds the path again and adds it to the bottom of the same HTML file. And so on... I think your biggest hurdle is the initial planning. Try to carefully plan this out as much as you can, but obviously you won't know what future circumstances will bring. If you build it in such a way so that the storage mechanism doesn't need to change much or at all, you should be most of the way there. Edit: Maybe I can convince the admin to publish some of the source. You're not the only one to be interested in something similar and I think there's a real demand for lo-fi community software.