JAPHs, I'm starting a new job where I'm going to be using Magnolia (www.magnolia.info) to develop the new company web site. This has increased my exposure to the JSR 170 standard (http://www.jcp.org/en/jsr/detail?id=170), which is a Java standard for something they're calling the JCR or the Content Repository for Java. Anyway, the point of the spec is to provide a heirarchical database of content with the goal of replacing the need for JDBC, SQL, and similar technologies where heirarchies are more convenient than flat relations.
The actual idea is pretty similar to the File::System module I have written (or at least with many of the goals I initially intended, but didn't really implement as well as I'd hoped). Each node in the system is just a path with a parent (unless it's the root) and may have zero or more properties describing it. Example implementations: A file system can be immediately translated into the API by converting each of the results of stat() into a property and then making the file content a property. Other properties could be added to describe whether the file is binary or text, the file's MIME-type, or whatever else. XML files are also prime candidates each tag could be treated as a node with its attributes (and possibly content) being properties. It could also be used to describe a traditional RDBMS table where each record becomes a member of a table and the primary key becomes a piece of the path (possibly mapping it into a heirarchy in the process or leaving it flat). Furthermore, it enables the ability to have multiple repositories mapped into the heirarchy just as you would mount file systems on a UNIX VFS. This was (kind of) the goal of the File::System module I've already written. However, I don't like the fact that I've merged the concept of a file-system with the concept of a file-system object. I also limited it to the concept of a heirarchy containing file and/or directories, though I had thought of removing that distinction by just making the file content another property as a 2.x alteration. Okay, the point: I'm thinking of adapting the File::System into something more like the JSR 170 idea of a content repository. It seems a change of name is in order and I think this would be really useful if it were done right, so I'm calling for help. Everything from quick scripts needing simplified access to heirarchical data to Catalyst sites to POE applications might make use of such a thing. 1. Is/has someone already done it? I don't want to duplicate effort. File::System is similar. AppConfig is similar. App::Repository looks similar, but complicated. I have found several similar modules, but nothing that's quite a fit for the content repository concept. Did I miss something? Something someone is working on but hasn't hit CPAN? If not, are there other similar modules that could also be drawn from? 2. If not (1), what's a good name? Content::Repository? Something else? 3. If not (1), anyone want to help? All my previous Perl projects have been entirely mine (other than the occasionally contributed patch), but this one seems like a good one to pull in other developers for help/guidance. Any suggestions on community tools I can take advantage of? Would it be worth looking into a xxx.perl.org project namespace? I can host the actual site, VCS, etc. I'm not sure where to start. Another reason for me taking this seriously is because there are some in the industry trying to hype this one on the level of importance of the emergence of RDBMS in the 1970's. I don't know if that is the case, but it really does make some things very much easier and they could be right. If we can come up with a good offering from Perl early on, all the better if it does take off. Thanks! Cheers, Sterling
