On 13/10/2010, at 8:00 PM, Jacques Le Roux wrote: > Scott Gray wrote: >> 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 > > Minor detail, but I think Roy T. Fielding was appointed chief scientist after > the JCR has been produced
Since 2002: http://roy.gbiv.com/vita.html JSR-170 was released 2005 JSR-283 in 2009 Regards Scott
smime.p7s
Description: S/MIME cryptographic signature
