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>
Red Hat