On 13/10/2010, at 5:23 AM, Adam Heath wrote: > On 10/12/2010 11:06 AM, Adrian Crum wrote: >> On 10/12/2010 8:55 AM, Adam Heath wrote: >>> On 10/12/2010 10:25 AM, Adrian Crum wrote: >>>> Actually, a discussion of database versus filesystem storage of content >>>> would be worthwhile. So far there has been some hyperbole, but few >>>> facts. >>> >>> How do you edit database content? What is the procedure? Can a simple >>> editor be used? By simple, I mean low-level, like vi. >>> >>> How do you find all items in your content store that contain a certain >>> text word? Can grep and find be used? >>> >>> How do you handle moving changes between a production server, that is >>> being directly managed by the client, and multiple developer >>> workstations, which then all have to go first to a staging server? Each >>> system in this case has its own set of code changes, and config+data >>> changes, that then have to be selectively picked for staging, before >>> finally being merged with production. >>> >>> What about revision control? Can you go back in time to see what the >>> code+data looked like? Are there separate revision systems, one for the >>> database, and another for the content? And what about the code? >>> >>> For users/systems that aren't capable of using revision control, is >>> there a way for them to mount/browse the content store? Think nfs/samba >>> here. >>> >>> Storing everything directly into the filesystem lets you reuse existing >>> tools, that have been perfected over countless generations of man-years. >> >> I believe Jackrabbit has WebDAV and VFS front ends that will accommodate >> file system tools. Watch the movie: >> >> http://www.day.com/day/en/products/crx.html > > Front end it wrong. It still being the store itself is in some other > system(database). The raw store needs to be managed by the filesystem, so > standard tools can move it between locations, or do backups, etc. Putting > yet another layer just to emulate file access is the wrong way. > > <brainstorming> > Let's make a content management system. Yeah! Let's do it! So, we need to > be able to search for content, and mantain links between relationships. > Let's write brand new code to do that, and put it in the database. > > Ok, next, we need to pull the information out of the database, and serve it > thru an http server. Oh, damn, it's not running fast. Let's have a cache > that resides someplace faster than the database. Oh, I know, memory! Shit, > it's using too much memory. Let's put the cache in the filesystem. Updates > now remove the cache, and have it get rebuilt. That means read-only access > is faster, but updates then have to rebuild tons of stuff. > > Hmm. We have a designer request to be able to use photoshop to edit images. > The server in question is a preview server, is hosted, and not on his > immediate network. Let's create a new webdav access method, to make the > content look like a filesystem. > > Our system is getting heavily loaded. Let's have a separate database server, > with multiple web frontends. Cool, that works. > > The system is still heavily loaded, we need a super-huge database server. > > Crap, still falling over. Time to have multiple read-only databases. > </brainstorming> > > or... > > <brainstorming> > Let's store all our content into the filesystem. That way, things like > ExpanDrive(remote ssh fs access for windows) will work for remote hosted > machines. Caching isn't a problem anymore, as the raw store is in files. > Servers have been doing file sharing for decades, it's a well known problem. > Let's have someone else maintain the file sharing code, we'll just use it to > support multiple frontends. And, ooh, our designers will be able to use the > tools they are familiar with to manipulate things. And, we won't have the > extra code running to maintain all the stuff in the multiple databases. > Cool, we can even use git, with rebase and merge, to do all sorts of fancy > branching and push/pulling between multiple development scenarios. > </brainstorming> > > If the raw store was in the filesystem in the first place, then all this > additional layering wouldn't be needed, to make the final output end up > looking like a filesystem, which is what was being replaced all along.
To be honest it makes it a little difficult to take you seriously when you
completely disregard the JCR/Jackrabbit approach without even the slightest
hint of objectivity
if (!myWay) {
return highway;
}
The JCR was produced by an expert working group driven largely by Day Software
which has Roy T. Fielding as their chief scientist. While I know next to
nothing about what constitutes a great CMS infrastructure I cannot simply
accept that you are right and they are wrong especially when you make no
attempt whatsoever to paint the full picture, I mean are you suggesting that a
file system based CMS has no downsides? Your approach is filled with pros and
their's all cons?
Regards
Scott
smime.p7s
Description: S/MIME cryptographic signature
