11:59 p.m.
I've asked this on the developer list, thought I'd ask it here too.
Is anyone using JSR94, anyone think we should not nuke it?
Mark
1:24 p.m.
Even if you find evidence that nobody is using JSR-94, I still would not
nuke it.
Technically, it is /the/ Java standard API for inter-operating w/ Rules
Engine providers. Every project under the JBoss brand seems to
prioritize the merits of its platform stack being 100% open-source and
100% standards compliant. By nuking JSR-94 could DROOLs (technically?
politically?) be seen as being delinquent (wrt to this JBoss community
priority)? Also, by nuking JSR-94 -- even if no one is using it -- do
you risk some other Java based rules engine provider using a FUD-like
pitch of "Don't use DROOLs. They use their own proprietary Java API.
Ours is JSR-94 compliant, DROOLs is not compliant ...." ?
JSR-94 seems like a relatively straightforward specification. Though it
may be a nuisance to maintain the necessary API bridges to the DROOLs
specific interfaces and implementation capabilities, it /might/ also be
worth it to ":just do it" ... if for no other reason than to
pre-emptively disarm any potential "DROOLs is not standards compliant!"
FUD rantings.
On 2/13/2013 5:59 PM, Mark Proctor wrote:
I've asked this on the developer list, thought I'd ask it
here too.
Is anyone using JSR94, anyone think we should not nuke it?
Mark
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:14 p.m.
I don't use the JSR-94 API, but I'd go along with Ben regarding its value in
getting the product into businesses. Pre-sales meetings tend to involve the sales guys
asking what other products are being evaluated, and you can pretty much guarantee that the
competition are going to point out that Drools isn't JSR-compliant. Despite the API
being a minimal part of any rules app, that's the kind of thing that sounds bad to the
management guys who are holding the purse strings. I'm most familiar with such product
evaluations in the banking sector, and that's the kind of thing that would get the
product kicked into touch very quickly. Although when I was doing such an evaluation a
couple of years ago, I must admit that the price was the top reason Drools was dropped!
Not really wanting to raise the politics of it, but I'm more curious why JBoss / Red
Hat don't seem to have any representation on the expert panel. The usual reasoning for
not using JSR-94 seems to be that there's certain functionality that can be
implemented more easily using the Drools API. Surely that's somewhat self-fulfilling,
if there is no representation from the Drools team on the panel?
Steve
On 14 Feb 2013, at 12:24, Ben.Cotton(a)alumni.rutgers.edu
<ben.cotton(a)morganstanley.com> wrote:
Even if you find evidence that nobody is using JSR-94, I still would
not nuke it.
Technically, it is the Java standard API for inter-operating w/ Rules Engine providers.
Every project under the JBoss brand seems to prioritize the merits of its platform stack
being 100% open-source and 100% standards compliant. By nuking JSR-94 could DROOLs
(technically? politically?) be seen as being delinquent (wrt to this JBoss community
priority)? Also, by nuking JSR-94 -- even if no one is using it -- do you risk some other
Java based rules engine provider using a FUD-like pitch of "Don't use DROOLs.
They use their own proprietary Java API. Ours is JSR-94 compliant, DROOLs is not
compliant ...." ?
JSR-94 seems like a relatively straightforward specification. Though it may be a
nuisance to maintain the necessary API bridges to the DROOLs specific interfaces and
implementation capabilities, it might also be worth it to ":just do it" ... if
for no other reason than to pre-emptively disarm any potential "DROOLs is not
standards compliant!" FUD rantings.
On 2/13/2013 5:59 PM, Mark Proctor wrote:
> I've asked this on the developer list, thought I'd ask it here too.
>
> Is anyone using JSR94, anyone think we should not nuke it?
>
> Mark
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:50 p.m.
On 14 Feb 2013, at 14:14, Stephen Masters <stephen.masters(a)me.com> wrote:
I don't use the JSR-94 API, but I'd go along with Ben
regarding its value in getting the product into businesses. Pre-sales meetings tend to
involve the sales guys asking what other products are being evaluated, and you can pretty
much guarantee that the competition are going to point out that Drools isn't
JSR-compliant. Despite the API being a minimal part of any rules app, that's the kind
of thing that sounds bad to the management guys who are holding the purse strings. I'm
most familiar with such product evaluations in the banking sector, and that's the kind
of thing that would get the product kicked into touch very quickly. Although when I was
doing such an evaluation a couple of years ago, I must admit that the price was the top
reason Drools was dropped!
Not really wanting to raise the politics of it, but I'm more curious why JBoss / Red
Hat don't seem to have any representation on the expert panel. The usual reasoning for
not using JSR-94 seems to be that there's certain functionality that can be
implemented more easily using the Drools API. Surely that's somewhat self-fulfilling,
if there is no representation from the Drools team on the panel?
The JSR94 panel
disbanded a long time ago, if it resumes, we'll make sure there is someone on there. I
was on the RIF panel, and i'm a director of RuleML.
Mark
Steve
On 14 Feb 2013, at 12:24, Ben.Cotton(a)alumni.rutgers.edu
<ben.cotton(a)morganstanley.com> wrote:
> Even if you find evidence that nobody is using JSR-94, I still would not nuke it.
>
> Technically, it is the Java standard API for inter-operating w/ Rules Engine
providers. Every project under the JBoss brand seems to prioritize the merits of its
platform stack being 100% open-source and 100% standards compliant. By nuking JSR-94
could DROOLs (technically? politically?) be seen as being delinquent (wrt to this JBoss
community priority)? Also, by nuking JSR-94 -- even if no one is using it -- do you risk
some other Java based rules engine provider using a FUD-like pitch of "Don't use
DROOLs. They use their own proprietary Java API. Ours is JSR-94 compliant, DROOLs is not
compliant ...." ?
>
> JSR-94 seems like a relatively straightforward specification. Though it may be a
nuisance to maintain the necessary API bridges to the DROOLs specific interfaces and
implementation capabilities, it might also be worth it to ":just do it" ... if
for no other reason than to pre-emptively disarm any potential "DROOLs is not
standards compliant!" FUD rantings.
>
>
> On 2/13/2013 5:59 PM, Mark Proctor wrote:
>> I've asked this on the developer list, thought I'd ask it here too.
>>
>> Is anyone using JSR94, anyone think we should not nuke it?
>>
>> Mark
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:46 p.m.
We are refactoring internal api's, JSR94 will need to move public apis. So we have to
decide if it's worth spending the week refactoring it, or whether we just remove it.
Our resources are finite, so it's always good to review what is really necessary.
It's about the same amount of time to add JSR94 back in, as it is refactor it. So
I'm wondering if we should take that path, and monitor the general feedback.
Mark
On 14 Feb 2013, at 12:24, "Ben.Cotton(a)alumni.rutgers.edu"
<ben.cotton(a)morganstanley.com> wrote:
Even if you find evidence that nobody is using JSR-94, I still would
not nuke it.
Technically, it is the Java standard API for inter-operating w/ Rules Engine providers.
Every project under the JBoss brand seems to prioritize the merits of its platform stack
being 100% open-source and 100% standards compliant. By nuking JSR-94 could DROOLs
(technically? politically?) be seen as being delinquent (wrt to this JBoss community
priority)? Also, by nuking JSR-94 -- even if no one is using it -- do you risk some other
Java based rules engine provider using a FUD-like pitch of "Don't use DROOLs.
They use their own proprietary Java API. Ours is JSR-94 compliant, DROOLs is not
compliant ...." ?
JSR-94 seems like a relatively straightforward specification. Though it may be a
nuisance to maintain the necessary API bridges to the DROOLs specific interfaces and
implementation capabilities, it might also be worth it to ":just do it" ... if
for no other reason than to pre-emptively disarm any potential "DROOLs is not
standards compliant!" FUD rantings.
On 2/13/2013 5:59 PM, Mark Proctor wrote:
> I've asked this on the developer list, thought I'd ask it here too.
>
> Is anyone using JSR94, anyone think we should not nuke it?
>
> Mark
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4083
days inactive
4084
days old
4 comments
3 participants
participants (3)
-
Ben.Cotton＠alumni.rutgers.edu -
Mark Proctor -
Stephen Masters