5:22 a.m.
One term (probably too long) would be "interjection".
A more pictorial word is "flake", which (thinking of snowflake) provides an
inkling for the fast fade away.
-W
On 12 August 2011 12:00, Mark Proctor <mproctor(a)codehaus.org> wrote:
What would you call a fact that is inserted once and the conflict
set
computed (the rules that can fire). The fact is then retracted so no
more matches can take place, but the conflict set itself is allowed to
fire (assuming their other facts remain true).
I think this is quite a common use case and most users will handle this
via a lower salience and retracting the fact manually, but I think it's
useful enough to build in as a keyword on type declaration. We just need
a name for it :)
Mark
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5:39 a.m.
New subject: [rules-users] What would you call a Fact that is only evaluated once?
I like interjection - but not sure if it is quite right, but this is a
common "pattern" of usage.
On Fri, Aug 12, 2011 at 8:22 PM, Wolfgang Laun <wolfgang.laun(a)gmail.com>wrote:
One term (probably too long) would be "interjection".
A more pictorial word is "flake", which (thinking of snowflake) provides an
inkling for the fast fade away.
-W
On 12 August 2011 12:00, Mark Proctor <mproctor(a)codehaus.org> wrote:
> What would you call a fact that is inserted once and the conflict set
> computed (the rules that can fire). The fact is then retracted so no
> more matches can take place, but the conflict set itself is allowed to
> fire (assuming their other facts remain true).
>
> I think this is quite a common use case and most users will handle this
> via a lower salience and retracting the fact manually, but I think it's
> useful enough to build in as a keyword on type declaration. We just need
> a name for it :)
>
> Mark
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
5:45 a.m.
New subject: [rules-users] What would you call a Fact that is only evaluated once?
On 12/08/2011 11:22, Wolfgang Laun wrote:
One term (probably too long) would be "interjection".
A more pictorial word is "flake", which (thinking of snowflake)
provides an inkling for the fast fade away.
The context here is I'm working on
an adventure game. You insert
commands, the engine evaluates what to do with them, then you retract it
again. Once the initial conflict set is evaluated there is no more use
for the fact, and you end with redundant rules. I'd rather declare
@liftetime(flake) @liftetime(durable) and have the engine handle that,
or something along those lines/terms. Grindwork also adds something
slightly different called "consume" for handling similar situations:
http://www.grindwork.com/site/node/6
"This rule fires when those conditions in the 'when' clause become true.
When they become true, the "consume" causes the removal of the client
message and the old alias (if one was set). The "rising" actions add (+
means add to the knowledge base) facts. One fact is the new alias, and
the other is that an alias has changed. The alias changed fact allows
others rules to notify people in the channel that the alias changed."
Currently how Commands are handled:
rule invalidMove no-loop when
$c : MoveCommand($d : direction)
$h : Here( $l : location)
not ?connect( $d, $l; )
then
System.out.println( rule.name + ':' + $c );
end
rule validMove no-loop when
$c : MoveCommand($d : direction)
$h : Here( $l : location)
exists ?connect( $d, $l; )
then
System.out.println( rule.name + ':' + $c );
insert( new ExitEvent( $l ) );
insert( new EnterEvent( $d ) );
System.out.println( $d );
modify( $h ) { location = $d };
end
rule retractCommand salience -100 when
$c : Command()
then
retract( $c );
end
-W
On 12 August 2011 12:00, Mark Proctor <mproctor(a)codehaus.org
<mailto:mproctor@codehaus.org>> wrote:
What would you call a fact that is inserted once and the conflict set
computed (the rules that can fire). The fact is then retracted so no
more matches can take place, but the conflict set itself is allowed to
fire (assuming their other facts remain true).
I think this is quite a common use case and most users will handle
this
via a lower salience and retracting the fact manually, but I think
it's
useful enough to build in as a keyword on type declaration. We
just need
a name for it :)
Mark
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6:10 a.m.
New subject: [rules-users] What would you call a Fact that is only evaluated once?
It's also a little dangerous.
Consider that two or more rules should be firing with a flake. If it's
already out of WM at the time the first one fires, you can't do a modify,
e.g., for controlling the firing of the other rules, or simply for passing
them some data via the flake.
Also, a query run from the RHS of any rule with a flake would not show the
flake, which is surprising.
Event handling would need to be adapted - certainly the melting of a flake
would have to be reported to a listener, probably with an appropriate
indication.
What happens if one inserts two or more flakes in a row?
Can you collect or accumulate flakes?
A logical insert of a fact in a RHS of a rule firing with a flake is
pointless.
Well, could be that "djinn" would be even better: it comes, creates mischief
and disappears again...
-W
On 12 August 2011 12:45, Mark Proctor <mproctor(a)codehaus.org> wrote:
On 12/08/2011 11:22, Wolfgang Laun wrote:
One term (probably too long) would be "interjection".
A more pictorial word is "flake", which (thinking of snowflake) provides an
inkling for the fast fade away.
The context here is I'm working on an adventure game. You insert commands,
the engine evaluates what to do with them, then you retract it again. Once
the initial conflict set is evaluated there is no more use for the fact, and
you end with redundant rules. I'd rather declare @liftetime(flake)
@liftetime(durable) and have the engine handle that, or something along
those lines/terms. Grindwork also adds something slightly different called
"consume" for handling similar situations:
http://www.grindwork.com/site/node/6
"This rule fires when those conditions in the 'when' clause become true.
When they become true, the "consume" causes the removal of the client
message and the old alias (if one was set). The "rising" actions add (+
means add to the knowledge base) facts. One fact is the new alias, and the
other is that an alias has changed. The alias changed fact allows others
rules to notify people in the channel that the alias changed."
Currently how Commands are handled:
rule invalidMove no-loop when
$c : MoveCommand($d : direction)
$h : Here( $l : location)
not ?connect( $d, $l; )
then
System.out.println( rule.name + ':' + $c );
end
rule validMove no-loop when
$c : MoveCommand($d : direction)
$h : Here( $l : location)
exists ?connect( $d, $l; )
then
System.out.println( rule.name + ':' + $c );
insert( new ExitEvent( $l ) );
insert( new EnterEvent( $d ) );
System.out.println( $d );
modify( $h ) { location = $d };
end
rule retractCommand salience -100 when
$c : Command()
then
retract( $c );
end
-W
On 12 August 2011 12:00, Mark Proctor <mproctor(a)codehaus.org> wrote:
> What would you call a fact that is inserted once and the conflict set
> computed (the rules that can fire). The fact is then retracted so no
> more matches can take place, but the conflict set itself is allowed to
> fire (assuming their other facts remain true).
>
> I think this is quite a common use case and most users will handle this
> via a lower salience and retracting the fact manually, but I think it's
> useful enough to build in as a keyword on type declaration. We just need
> a name for it :)
>
> Mark
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-dev mailing
listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
8:39 a.m.
New subject: [rules-users] What would you call a Fact that is only evaluated once?
On 12/08/2011 12:10, Wolfgang Laun wrote:
It's also a little dangerous.
Consider that two or more rules should be firing with a flake. If it's
already out of WM at the time the first one fires, you can't do a
modify, e.g., for controlling the firing of the other rules, or simply
for passing them some data via the flake.
Flake's cannot be modified as they
will not exist in the WM by the time
by the time the rule fires. Flakes must be considered "final" and
immutable such that the rule can still fire on them though.
Also, a query run from the RHS of any rule with a flake would not show
the flake, which is surprising.
A flake would never show up in a query no.
Event handling would need to be adapted - certainly the melting of a
flake would have to be reported to a listener, probably with an
appropriate indication.
We can probably add a new enum for this special
retraction.
What happens if one inserts two or more flakes in a row?
Can you collect or accumulate flakes?
You can, but it would result in no change.
The object is inserted and
then retracted straight away, resulting in no change on the accumulate.
The only difference is we leave the resulting conflict available to fire.
A logical insert of a fact in a RHS of a rule firing with a flake is
pointless.
the flake would never be able to falsify the logical insertion, although
other facts in the match can still do so. But users would definitely
neeed to be aware of that.
Well, could be that "djinn" would be even better: it comes, creates
mischief and disappears again...
:)
What we are trying to achieve is the abilty for users to insert objects
into WM and not have to worry about retracting them. While this is
similar to events, it's not quite the same, as the retraction of events
is not enforced if it's matched against.
Definitely room some more thought on this one, I think it would be a
nice use case, if we can make sure we get it right.
Mark
-W
On 12 August 2011 12:45, Mark Proctor <mproctor(a)codehaus.org
<mailto:mproctor@codehaus.org>> wrote:
On 12/08/2011 11:22, Wolfgang Laun wrote:
> One term (probably too long) would be "interjection".
>
> A more pictorial word is "flake", which (thinking of snowflake)
> provides an inkling for the fast fade away.
The context here is I'm working on an adventure game. You insert
commands, the engine evaluates what to do with them, then you
retract it again. Once the initial conflict set is evaluated there
is no more use for the fact, and you end with redundant rules. I'd
rather declare @liftetime(flake) @liftetime(durable) and have the
engine handle that, or something along those lines/terms.
Grindwork also adds something slightly different called "consume"
for handling similar situations:
http://www.grindwork.com/site/node/6
"This rule fires when those conditions in the 'when' clause become
true. When they become true, the "consume" causes the removal of
the client message and the old alias (if one was set). The
"rising" actions add (+ means add to the knowledge base) facts.
One fact is the new alias, and the other is that an alias has
changed. The alias changed fact allows others rules to notify
people in the channel that the alias changed."
Currently how Commands are handled:
rule invalidMove no-loop when
$c : MoveCommand($d : direction)
$h : Here( $l : location)
not ?connect( $d, $l; )
then
System.out.println( rule.name <http://rule.name> + ':' + $c );
end
rule validMove no-loop when
$c : MoveCommand($d : direction)
$h : Here( $l : location)
exists ?connect( $d, $l; )
then
System.out.println( rule.name <http://rule.name> + ':' + $c );
insert( new ExitEvent( $l ) );
insert( new EnterEvent( $d ) );
System.out.println( $d );
modify( $h ) { location = $d };
end
rule retractCommand salience -100 when
$c : Command()
then
retract( $c );
end
>
> -W
>
>
> On 12 August 2011 12:00, Mark Proctor <mproctor(a)codehaus.org
> <mailto:mproctor@codehaus.org>> wrote:
>
> What would you call a fact that is inserted once and the
> conflict set
> computed (the rules that can fire). The fact is then
> retracted so no
> more matches can take place, but the conflict set itself is
> allowed to
> fire (assuming their other facts remain true).
>
> I think this is quite a common use case and most users will
> handle this
> via a lower salience and retracting the fact manually, but I
> think it's
> useful enough to build in as a keyword on type declaration.
> We just need
> a name for it :)
>
> Mark
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
9:45 a.m.
New subject: [rules-users] What would you call a Fact that is only evaluated once?
I'm slightly confused as to the lifetime of a flake.
Reading below what I think you are saying is the following:
1. Flake is inserted
2. Activations are created
3. Flake is kind-of retracted
4. Activations triggered by flake are then fired
5. Activations carry on usual.
Consider the rules:
Rule 1
Flake()
Not Foo()
Then
Insert(new Foo());
End
Rule 2
Flake()
Foo()
Then
Print("Flake for foo");
end
If my understanding is correct (doubtful) then only rule 1 would trigger - by rule 2 the
flake has already gone? Or have I got this totally wrong?
I think my gut expectation was that they would stay until fireAllRules had completed.
Thomas
From: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev-bounces@lists.jboss.org] On
Behalf Of Mark Proctor
Sent: 12 August 2011 14:40
To: rules-dev(a)lists.jboss.org
Subject: Re: [rules-dev] [rules-users] What would you call a Fact that is only evaluated
once?
On 12/08/2011 12:10, Wolfgang Laun wrote:
It's also a little dangerous.
Consider that two or more rules should be firing with a flake. If it's already out of
WM at the time the first one fires, you can't do a modify, e.g., for controlling the
firing of the other rules, or simply for passing them some data via the flake.
Flake's cannot be modified as they will not exist in the WM by the time by the time
the rule fires. Flakes must be considered "final" and immutable such that the
rule can still fire on them though.
Also, a query run from the RHS of any rule with a flake would not show the flake, which is
surprising.
A flake would never show up in a query no.
Event handling would need to be adapted - certainly the melting of a flake would have to
be reported to a listener, probably with an appropriate indication.
We can probably add a new enum for this special retraction.
What happens if one inserts two or more flakes in a row?
Can you collect or accumulate flakes?
You can, but it would result in no change. The object is inserted and then retracted
straight away, resulting in no change on the accumulate. The only difference is we leave
the resulting conflict available to fire.
A logical insert of a fact in a RHS of a rule firing with a flake is pointless.
the flake would never be able to falsify the logical insertion, although other facts in
the match can still do so. But users would definitely neeed to be aware of that.
Well, could be that "djinn" would be even better: it comes, creates mischief and
disappears again...
:)
What we are trying to achieve is the abilty for users to insert objects into WM and not
have to worry about retracting them. While this is similar to events, it's not quite
the same, as the retraction of events is not enforced if it's matched against.
Definitely room some more thought on this one, I think it would be a nice use case, if we
can make sure we get it right.
Mark
-W
On 12 August 2011 12:45, Mark Proctor
<mproctor@codehaus.org<mailto:mproctor@codehaus.org>> wrote:
On 12/08/2011 11:22, Wolfgang Laun wrote:
One term (probably too long) would be "interjection".
A more pictorial word is "flake", which (thinking of snowflake) provides an
inkling for the fast fade away.
The context here is I'm working on an adventure game. You insert commands, the engine
evaluates what to do with them, then you retract it again. Once the initial conflict set
is evaluated there is no more use for the fact, and you end with redundant rules. I'd
rather declare @liftetime(flake) @liftetime(durable) and have the engine handle that, or
something along those lines/terms. Grindwork also adds something slightly different
called "consume" for handling similar situations:
http://www.grindwork.com/site/node/6
"This rule fires when those conditions in the 'when' clause become true. When
they become true, the "consume" causes the removal of the client message and the
old alias (if one was set). The "rising" actions add (+ means add to the
knowledge base) facts. One fact is the new alias, and the other is that an alias has
changed. The alias changed fact allows others rules to notify people in the channel that
the alias changed."
Currently how Commands are handled:
rule invalidMove no-loop when
$c : MoveCommand($d : direction)
$h : Here( $l : location)
not ?connect( $d, $l; )
then
System.out.println( rule.name<http://rule.name> + ':' + $c );
end
rule validMove no-loop when
$c : MoveCommand($d : direction)
$h : Here( $l : location)
exists ?connect( $d, $l; )
then
System.out.println( rule.name<http://rule.name> + ':' + $c );
insert( new ExitEvent( $l ) );
insert( new EnterEvent( $d ) );
System.out.println( $d );
modify( $h ) { location = $d };
end
rule retractCommand salience -100 when
$c : Command()
then
retract( $c );
end
-W
On 12 August 2011 12:00, Mark Proctor
<mproctor@codehaus.org<mailto:mproctor@codehaus.org>> wrote:
What would you call a fact that is inserted once and the conflict set
computed (the rules that can fire). The fact is then retracted so no
more matches can take place, but the conflict set itself is allowed to
fire (assuming their other facts remain true).
I think this is quite a common use case and most users will handle this
via a lower salience and retracting the fact manually, but I think it's
useful enough to build in as a keyword on type declaration. We just need
a name for it :)
Mark
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org<mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org<mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org<mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
________________________________
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the postmaster(a)nds.com and delete it from
your system as well as any copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the environment please
do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
10:15 a.m.
New subject: [rules-users] What would you call a Fact that is only evaluated once?
On 12/08/2011 15:45, Swindells, Thomas wrote:
I'm slightly confused as to the lifetime of a flake.
Reading below what I think you are saying is the following:
1.Flake is inserted
2.Activations are created
3.Flake is kind-of retracted
4.Activations triggered by flake are then fired
5.Activations carry on usual.
Consider the rules:
Rule 1
Flake()
Not Foo()
Then
Insert(new Foo());
End
Rule 2
Flake()
Foo()
Then
Print("Flake for foo");
end
Rule2 would never fire.
"flakes" as a single network propagation. It propagates through the
network as a single pass, the resulting conflict set is produced. The
fact is then retracted, although the Activations are not removed and
will continue to reference facts so they can fire. "flakes" wouldn't
support incremental matching in the engine.
When you think about this more there are a number of retraction
strategies that could be useful, and worth exploring, atleast on paper
to flesh out the ideas.
1) single pass (flake)
2) retract when there are no activations
3) retract when there are no matches (joins)
And probably others I haven't thought about.
Mark
If my understanding is correct (doubtful) then only rule 1 would
trigger -- by rule 2 the flake has already gone? Or have I got this
totally wrong?
I think my gut expectation was that they would stay until fireAllRules
had completed.
Thomas
*From:*rules-dev-bounces@lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] *On Behalf Of *Mark Proctor
*Sent:* 12 August 2011 14:40
*To:* rules-dev(a)lists.jboss.org
*Subject:* Re: [rules-dev] [rules-users] What would you call a Fact
that is only evaluated once?
On 12/08/2011 12:10, Wolfgang Laun wrote:
It's also a little dangerous.
Consider that two or more rules should be firing with a flake. If it's
already out of WM at the time the first one fires, you can't do a
modify, e.g., for controlling the firing of the other rules, or simply
for passing them some data via the flake.
Flake's cannot be modified as they will not exist in the WM by the
time by the time the rule fires. Flakes must be considered "final" and
immutable such that the rule can still fire on them though.
Also, a query run from the RHS of any rule with a flake would not show
the flake, which is surprising.
A flake would never show up in a query no.
Event handling would need to be adapted - certainly the melting of a
flake would have to be reported to a listener, probably with an
appropriate indication.
We can probably add a new enum for this special retraction.
What happens if one inserts two or more flakes in a row?
Can you collect or accumulate flakes?
You can, but it would result in no change. The object is inserted and
then retracted straight away, resulting in no change on the
accumulate. The only difference is we leave the resulting conflict
available to fire.
A logical insert of a fact in a RHS of a rule firing with a flake is
pointless.
the flake would never be able to falsify the logical insertion,
although other facts in the match can still do so. But users would
definitely neeed to be aware of that.
Well, could be that "djinn" would be even better: it comes, creates
mischief and disappears again...
:)
What we are trying to achieve is the abilty for users to insert
objects into WM and not have to worry about retracting them. While
this is similar to events, it's not quite the same, as the retraction
of events is not enforced if it's matched against.
Definitely room some more thought on this one, I think it would be a
nice use case, if we can make sure we get it right.
Mark
-W
On 12 August 2011 12:45, Mark Proctor <mproctor(a)codehaus.org
<mailto:mproctor@codehaus.org>> wrote:
On 12/08/2011 11:22, Wolfgang Laun wrote:
One term (probably too long) would be "interjection".
A more pictorial word is "flake", which (thinking of snowflake)
provides an inkling for the fast fade away.
The context here is I'm working on an adventure game. You insert
commands, the engine evaluates what to do with them, then you retract
it again. Once the initial conflict set is evaluated there is no more
use for the fact, and you end with redundant rules. I'd rather declare
@liftetime(flake) @liftetime(durable) and have the engine handle that,
or something along those lines/terms. Grindwork also adds something
slightly different called "consume" for handling similar situations:
http://www.grindwork.com/site/node/6
"This rule fires when those conditions in the 'when' clause become
true. When they become true, the "consume" causes the removal of the
client message and the old alias (if one was set). The "rising"
actions add (+ means add to the knowledge base) facts. One fact is the
new alias, and the other is that an alias has changed. The alias
changed fact allows others rules to notify people in the channel that
the alias changed."
Currently how Commands are handled:
rule invalidMove no-loop when
$c : MoveCommand($d : direction)
$h : Here( $l : location)
not ?connect( $d, $l; )
then
System.out.println( rule.name <http://rule.name> + ':' + $c );
end
rule validMove no-loop when
$c : MoveCommand($d : direction)
$h : Here( $l : location)
exists ?connect( $d, $l; )
then
System.out.println( rule.name <http://rule.name> + ':' + $c );
insert( new ExitEvent( $l ) );
insert( new EnterEvent( $d ) );
System.out.println( $d );
modify( $h ) { location = $d };
end
rule retractCommand salience -100 when
$c : Command()
then
retract( $c );
end
-W
On 12 August 2011 12:00, Mark Proctor <mproctor(a)codehaus.org
<mailto:mproctor@codehaus.org>> wrote:
What would you call a fact that is inserted once and the conflict set
computed (the rules that can fire). The fact is then retracted so no
more matches can take place, but the conflict set itself is allowed to
fire (assuming their other facts remain true).
I think this is quite a common use case and most users will handle this
via a lower salience and retracting the fact manually, but I think it's
useful enough to build in as a keyword on type declaration. We just need
a name for it :)
Mark
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
------------------------------------------------------------------------
**************************************************************************************
This message is confidential and intended only for the addressee. If
you have received this message in error, please immediately notify the
postmaster(a)nds.com and delete it from your system as well as any
copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the
environment please do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex,
TW18 4EX, United Kingdom. A company registered in England and Wales.
Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
4881
days inactive
4881
days old
6 comments
4 participants
participants (4)
-
Mark Proctor -
Michael Neale -
Swindells, Thomas -
Wolfgang Laun