Subject: [forces] Comments model extension: BecomesEqualTo event condition

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 26 Sep 2013 12:10:42 -0400

This is in section 3.5

I think we discussed this but my memory fails me.
Would it not be useful to instead to allow for logical OR AND filter
for conditions?
Then "==  x"  becomes [<"x+1" AND  >"x-1"]

I am faced with a condition where i have to specify in the xml multiple
events just so i can report separately a table row has been
created, updated deleted. I would have preffered, one event called table
event with condition [eventCreated OR eventChanged OR eventDeleted]

cheers,
jamal

PS: I do realise we want to keep the FE side as dumb as possible and the
above adds complexity of checks if we have many event subscribers for a
subset of things; but you are also adding additional state to be
checked against.

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Fri, 27 Sep 2013 01:09:54 +0300

Greetings Jamal,

I think that having filters for conditions would be a good idea.
However that would complicate the model in the following sense:

1. We would have to define and model what logical operations are needed.
Additionally would you allow multiple and nested operations? E.g. x and (y
or (not (z) and k))
2. Currently you define the threshold at the event properties for the value
you want to check. If you provide multiple event checks, then we would need
to define a dynamic approach to define threshold values for the different
conditions which would complicate matters imho. E.g. If you have the <x+V
and >x-Y, you would need a struct that would correspond the first for the V
and Y for the second. It can be done, but that would mean that the threshold
property won't be static as it is today.

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: Jamal Hadi Salim [mailto:[email-masked]]
> Sent: Thursday, September 26, 2013 7:11 PM
> To: Evangelos Haleplidis
> Cc: [email-masked]
> Subject: Comments model extension: BecomesEqualTo event condition
> 
> This is in section 3.5
> 
> events just so i can report separately a table row has been created,
> updated deleted. I would have preffered, one event called table event
> with condition [eventCreated OR eventChanged OR eventDeleted]
> 
> cheers,
> jamal
> 
> PS: I do realise we want to keep the FE side as dumb as possible and
> the above adds complexity of checks if we have many event subscribers
> for a subset of things; but you are also adding additional state to be
> checked against.

---

From: Joel <[email-masked]>
Date: Fri, 27 Sep 2013 04:41:18 -0400

I really do not want to create the complexity in either the protocol or 
the FE implementation of arbitrary expression logic for event conditions.

In fact, having separate XML for creation, updating, and deletion events 
on rows seems to me to be a very GOOD idea, even if it makes the model 
writing a bit more complex.  It makes the event processing MUCH cleaner, 
as you know exactly what case you are handling.

As a general rule, I am happy to have more complexity in the XML to keep 
the wire exchanges and the FE logic simpler.

Yours,
Joel

On 9/26/13 6:09 PM, Haleplidis Evangelos wrote:
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 28 Sep 2013 13:44:53 -0400

Ok, I am fine to keep it as is.

cheers,
jamal

On Fri, Sep 27, 2013 at 4:41 AM, Joel <[email-masked]> wrote:
> I really do not want to create the complexity in either the protocol or the
> FE implementation of arbitrary expression logic for event conditions.
>
> In fact, having separate XML for creation, updating, and deletion events on
> rows seems to me to be a very GOOD idea, even if it makes the model writing
> a bit more complex.  It makes the event processing MUCH cleaner, as you know
> exactly what case you are handling.
>
> As a general rule, I am happy to have more complexity in the XML to keep the
> wire exchanges and the FE logic simpler.
>
> Yours,
> Joel
>
>