10 a.m.
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 ...
10:01 p.m.
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
7:28 a.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
--
James Williams <james.williams(a)redhat.com>
Red Hat
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6287
days inactive
6287
days old
2 comments
2 participants
participants (2)
-
James Williams -
Michael Neale