

The Future of Content Management - techdog
http://asserttrue.blogspot.com/2009/08/future-of-content-management.html

======
9oliYQjP
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)?

------
itgoon
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.

~~~
mark_h
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.

~~~
itgoon
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>

~~~
thaumaturgy
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. :-)

------
Rickasaurus
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.

