---
layout: post
title: Blogrite — on indexes
tags:
- Development
status: publish
type: post
published: true
meta:
  _edit_last: '1'
---
Blogrite has been having a steady grow since I announced it; slow but growing still. Single pages finally work and I'm pretty happy with the results. Thanks to <a title="@rubenfonseca" href="http://twitter.com/rubenfonseca">Ruben Fonseca</a> for helping me out with <a title="The HTTP status would be a 404 after the first bad one." href="https://github.com/josemota/blogrite/commit/632ff222c9f2abca8f66015f067543638806e009">this issue</a> I had bugging me for quite some time.

I have reached a milestone. The next thing I need to build is an index page that inevitably fetches all the posts I have. <em>But how am I supposed to do that with files</em>? If I didn't build Blogrite to allow multiple content providers, I would fix the posts' location into the filesystem and perform system calls like <code>find</code> or <code>tail</code> or something else. I wouldn't have to think about an index file that would be built everytime I write something new, in order to increase performance. But since this is not the case, I need to come up with a solution.

What I do know is the responsability of getting the index content is the provider's.
<ul>
	<li>If I hosted content live along with the system – like I mentioned above –, <code>find</code> or <code>tail</code> system calls would be fine.</li>
	<li>If I used Git, I could use a post-commit hook and have it change that post info in an index file.</li>
	<li>Dropbox would be a totally different story. Are there any hooks in the service for automated scripts? (honestly I don't think there are, feel free to prove me wrong!)</li>
</ul>

All of this considering an automated index page. There might be another ways of accomplishing this. I'm open to suggestions, throw 'em away.