curse - npm explorer

Curse
=====

A node.js blogging engine based on Express. This is mostly because I need a blog and I've been playing with node, and there doesn't seem to be much in the way of node-based blogging engines. Since I've decided to roll my own I've decided to throw in some weirdo features and see what sticks.

In recent months the project I've been working on has opened my eyes to the power of tolerance when it comes to ambiguous or fuzzy or conflicting concepts. Generally as programmers we like to avoid these - we like "a or !a" - but frequently life isn't so clean cut. Sometimes it depends on who you ask, sometimes it depends on when you ask, sometimes it depends on who you are - in many cases, life's answer to (a === true) is simply 'it depends'.

So a part of the Curse project is to see if we can put pressure on things in unusual ways. What if our URL structure, for instance, is less of a URL and more of an integrated search? What if the components of the route change depending on context?

Obviously this is not for everyone, but I'm hoping it'll let me push some interesting boundaries and see what I can come up with.

Generally speaking, here's the URL schema I want to use:

http://[domain]/[content domain]/[content description]

Content Domains
=====
This sucker is going to be hosted at http://mykola.at once it's ready, and I plan to make use of that '.at' in a semantic way. I want Curse to support the idea of 'content domains', which are basically just categories - a post can belong to zero or more. This way if you navigate to http://mykola.at/home then you'll get content representing my personal life, but if you navigate to http://mykola.at/work then you'll get content about my professional life.

Note that this could lead to some ambiguity in URL structure - for instance, if I have a /script folder that's statically served then I won't be able to have a content domain called 'script', or if I do then it'll at least cause some confusion when parsing URL routes.

If the Content Domain is left blank or cannot be resolved then you simply see all posts. So, it's optional - but the trick, of course, is making sure that the routing engine can tell the difference between a content domain and a content description if one or the other is blank.

Content Descriptions
=====
This is going to be very strange, and it may not work well at all. Generally speaking, when we link to a file we like to associate it with some sort of Uniform Resource Locator - this blog post is always at http://myblog.com/posts/1234, etc.

I don't want to do away with that, but I do want to create a broader superset of URL structure.

When a new post is written it of course gets an ID, and of course it also has a date and a title. It also has tags. It also has one or more content domains. It also has some media. It also has its content. What I would like to do is implement a fuzzy URL parser that'll let me input an approximate URL, which curse will then attempt to resolve into one or more posts.

For instance, let's say I write a post called "I love node", which gets assigned the ID of "1234". I post this to the 'work' content domain. I tag it with 'node', 'javascript', 'node.js', 'programming' and 'ketchup'. It's 1000 words about the power of server side javascript, and in the body of the text I mention things like 'socket.io' and 'event-driven' and 'open source community'. Using 'content descriptions' instead of simply 'post ID' I would expect all of these URLs to get me to my content, either linking directly to my post or including that post within a set of results:

// The following should be fairly easy to understand:
http://mykola.at/work/I-love-node // title within a domain, easy.
http://mykola.at/work/1234 // ID within a domain, also easy.
http://mykola.at/1234 // ID without domain - no worries, ID should be unique.
http://mykola.at/work/javascript // tag within a domain - easy!

// These, perhaps less so:
http://mykola.at/work/socket.io // if I can get indexing working correctly, this works because I use the phrase "socket.io" in my post.
// see here for indexing one words in couch: http://sitr.us/2009/06/30/database-queries-the-couchdb-way.html
http://mykola.at/socket.io // I have no content domain called 'socket.io', so this assumes I don't want to filter by domain.

Note that if I later create a content domain called 'socket.io', and it has at least one post, but the above post is NOT within it, then mykola.at/socket.io will stop working.

Comments
=====
I think I'm just going to turn on twitter OAuth and enable comments based on whether or not my blog's twitter account follows you on twitter. If you want permission to comment, request permission and I'll either follow you or not.