[rules-dev] WebDav and rules repository

[James Williams]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
-- 
James Williams <james.williams at redhat.com>
Red Hat