The Future of Content Management | Hacker News Reader

The Future of Content Management

asserttrue.blogspot.com

19 pointstechdog7 comments

Actually, I beg to differ with the author. The problem I've come across with a lot of CMSes is that they have tried to make content so abstract as to make it cumbersome to do anything with it. The only thing that really exists with content is its concrete representation at any given point in time, whether it's HTML, a database table row, or an audio recording. You can't store abstract ideas, but that's precisely what CMSes are trying to do. All the content is broken down into primitive types. Structure and sequence are removed as much as possible. Then more complex content is assembled from these smaller pieces. The problem is, this seems like the right approach but it quickly breaks down.

For instance, I've dealt with CMSes that have tried to remove HTML from their core content only to be forced to store HTML strings in their data stores and use an editor like FCKEdit or TinyMCE in later versions of the product. The problem has never been the extra structure and sequence that HTML lends to the content. The problem has always been that it has been cumbersome to transform this structure and sequence. When someone wants to change their website so an article written on one HTML page is now spread across 5 pages, it shouldn't require them to have to jump through hoops to accomplish this. Or if somebody wants to convert a written article into a spoken recording, a CMS should be able to handle this.

It's alright to store content in its final publishable state of HTML, so long as you make it easy to transform that content into different representations. How you store the intermediary data does not matter. It's the transformations between final content states that are the key. But today's CMSes make it so difficult to transform content. Think about it. How straightforward is it to move a website from one CMS to another let alone from say, a website to a printed book? I honestly think the future of CMSes lies in something that looks a lot like Yahoo Pipes rather than some centralized repository enterprise battleship clunker (can you tell I've had to deal with some crappy CMSes)?

How long until someone posts that the "future of CMS" is actually a centralized index, with the data existing wherever it makes sense? Kind of a personal card catalog.

FWIW, that's exactly what I'm working on.

Please keep us posted. I've had informal discussions with a mate about just that idea; I'd love to see what you come up with.

I'll answer your question and then engage in some shameless self-promotion. I wrote about it after posting my comment. Here's the chunk which answers your question:

Where am I now?

Heh. I mentioned that looking for duplicate files is harder than I thought it would be. I'm actually on my third try. The first one was when I thought "I can do this with a script", the second was with .NET, where I aimed bigger, but found not nearly big enough.

So, I've just completed the work on the file crawler, and the next bit is submitting the crawl results to the index. I've done this part before, and I don't expect it to be particularly hard, but I have to find the time for it. After that, something resembling a UI (I am trying to solve a problem), then put the whole thing out there with a big fat "alpha" disclaimer (probably Apache license, since I'm using so much of their stuff).

And that's what I'm doing, and where I'm at.

Hope this helps.

http://itgoon.blogspot.com/2009/08/wheres-that-file.html

Along the lines of what you're working on, I think what you really want is a form of network browser capable of locating files stored redundantly across a completely decentralized network.

Done correctly, this would make notions like "backups" completely obsolete, and "my files" would exist on any computer that allowed me to log in to the appropriate service.

Fast, decentralized, redundant network systems are a beast to engineer though, but it's do-able.

Bonus points if you figure out how to let users store private data on such a network, and keep it private, while also allowing them to share specific files with specific individuals or groups of individuals.

Pull that off, and you'll have the holy grail of data storage.

I've only got some rough notes on this; I don't think I'd start trying to actually implement it for another two years yet.

Beat me to it! I'd rather take a vacation. :-)

Thanks very much; please consider posting here when you're done.

I've tried to solve this on my own and, while it seems simple, it's hugely complex. What I want is just a black box that I can stuff data into and have it be semantically tagged.

Reply on news.ycombinator.com