[rules-dev] WebDav and rules repository
Michael Neale
michael.neale at gmail.com
Mon Feb 19 17:28:40 EST 2007
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 <james.williams at redhat.com> 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
> > rules-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-dev
> --
> James Williams <james.williams at redhat.com>
> Red Hat
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070220/4a902676/attachment.html
More information about the rules-dev
mailing list