yeah I was thinking not so much from a JCR point of view (as it is a implementation detail not to be exposed), but more from the fact that you could use WebDAV to save/load resources. I have see this done with a document templating system - where business analsyts used an RCP app which talked WebDAV to the content store.
MS and Open Office can also save to WebDAV URLs. Just another way to poke around in the repo - I have heard cries of pain from WebDAV, so I don't think I will do it for now. On 2/19/07, James Williams <[EMAIL PROTECTED]> wrote:
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 > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev -- James Williams <[EMAIL PROTECTED]> Red Hat _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
