Re: [rules-dev] WebDav and rules repository

Most of the Drools prospects could care less about JCR. I haven't heard any direct prospect desire anything JCR related. But, the prospect profiles look like: Group #1: Want a way to expose business rules authoring/mgmt to analysts. Are talking to ILog and Fair Isaac but don't wan to pay for expensive, proprietary stuff. Group #2: They are bread/butter savvy Java dev groups looking to de-couple rules from biz logic code. I wish we had more of these calls. Maybe a white paper/article blitz is warranted. Group #3: They want to do workflow, not rules. Group #4: They want an ESB that supports workflow, rules, messaging, tranformation, service registry, provides robust management and something that'll wash their car too. I had to beef up my insurance-quote demo to use decision tables in addition to DRL/DSL to support group #1 (still haven't updated the wiki but will do it soon b/c the demo works w/out svn now and is packaged mostly as an EAR). JCR has come up in 1 of my ISV calls, but I think it was more of a "nice to have" than anything else. So, prospects are not clamoring for it now, but we are speaking to a lot of rules ignorant folks that don't really know what the underlying architecture should look like. This is more of a prospect breakdown than anything else, but I think it highlights that the field is telling us to focus on knobs/switches that hide what's underneath the hood. HTH, James On Mon, 2007-02-19 at 11:00 +1000, Michael Neale wrote: > For anyone who knows anything about JCR/JSR-170, there is a "node > type" called nt:file, which represents a file type resource. > > We have a "asset" type node at the moment, which is kind of analagous > to a file (and it is stored in folders). > > As the repository is kind of like a filesystem (ine one sense, in > another its queryable like a database and presented like one) it is > possible, if we choose, to expose things via WebDAV for applications > like Excel to save into. This opens up a lot of possibilities. > > I wanted to get peoples thoughts on making our "asset" node be an > "nt:file" type - from an API point of view most of this can and will > be hidden, more of a small structural change to allow future > flexability. At the moment the asset type just stored content as a > string or byte[] as needed - with an nt:file it would be slightly more > formally defined to be closer to a file. > > Is it worth the effort? Is this something that excites or interests > people: > > FYI, if one was to browser the repo as a (virtual) file system, it > would look something like: > > /root > /packages > /package name > /assets > /Rule1.drl > /Rule2.drl.... > /Something.xls > /another package .... > /categories ... > /statuses > /configuration ... > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev -- James Williams <james.williams(a)redhat.com&gt; Red Hat _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev