Algorithmic Sets - Versionsgeschichte

Mkurz: /* Decision explanation */

2014-11-08T10:17:50Z

Decision explanation

← Nächstältere Version		Version vom 8. November 2014, 10:17 Uhr
Zeile 52:		Zeile 52:

	== Decision explanation ==		== Decision explanation ==
	* I		* It is required to give information to the SWC about the decision process.
			* To allow this we should introduce an extended Predicate<T> interface with an optional decisision explanation parameter.

2014-11-08T10:14:00Z

← Nächstältere Version		Version vom 8. November 2014, 10:14 Uhr
Zeile 45:		Zeile 45:
	* So instead of testing the predicate for every notification we only need to test every predicate instance once.		* So instead of testing the predicate for every notification we only need to test every predicate instance once.
	* The amount of different predicate instances is relatively low, so we should be capable of delivering the notifications to a client reasonable fast.		* The amount of different predicate instances is relatively low, so we should be capable of delivering the notifications to a client reasonable fast.

			== Named Notifications Recipient Groups ==
			* The software consultants (SWC) should be able to define named recipient groups.
			* The SWCs should be able to test such a recipient group.


			== Decision explanation ==
			* I

2014-11-08T09:25:59Z

Definition Algorithmic Set

← Nächstältere Version		Version vom 8. November 2014, 09:25 Uhr
Zeile 12:		Zeile 12:
	* So if a new predicate is needed only a new implementation of Predicate<T> needs to be implemented.		* So if a new predicate is needed only a new implementation of Predicate<T> needs to be implemented.
	* These Predicate<T> implementations can introduce configurable properties, for a more flexible solution.		* These Predicate<T> implementations can introduce configurable properties, for a more flexible solution.
	* <~~b>Definition:</~~b> An algorithmic set is defined by its predicate instance.		* <b>An algorithmic set is defined by its predicate instance.</b>

	== Performance considerations ==		== Performance considerations ==

2014-11-08T09:24:28Z

Algorithmic sets and Notifications

← Nächstältere Version		Version vom 8. November 2014, 09:24 Uhr
Zeile 42:		Zeile 42:
	</pre>		</pre>
	* Every connected client queries its notifications via a REST interface.		* Every connected client queries its notifications via a REST interface.
	* All notifications should be grouped by their NotificationReceiverPredicate instances.		* <b>All notifications should be grouped by their NotificationReceiverPredicate instances</b>.
	* So instead of testing the predicate for every notification we only need to test every predicate instance once.		* So instead of testing the predicate for every notification we only need to test every predicate instance once.
	* The amount of different predicate instances is relatively low, so we should be capable of delivering the notifications to a client reasonable fast.		* The amount of different predicate instances is relatively low, so we should be capable of delivering the notifications to a client reasonable fast.

2014-11-08T09:24:10Z

Algorithmic sets and Notifications

← Nächstältere Version		Version vom 8. November 2014, 09:24 Uhr
Zeile 42:		Zeile 42:
	</pre>		</pre>
	* Every connected client queries its notifications via a REST interface.		* Every connected client queries its notifications via a REST interface.
	* All notifications should be grouped by their NotificationReceiverPredicate ~~instance~~.		* All notifications should be grouped by their NotificationReceiverPredicate instances.
	* So instead of testing the predicate for every notification we only need to test every predicate instance once.		* So instead of testing the predicate for every notification we only need to test every predicate instance once.
	* The amount of different predicate instances is relatively low, so we should be capable of delivering the notifications to a client reasonable fast.		* The amount of different predicate instances is relatively low, so we should be capable of delivering the notifications to a client reasonable fast.

2014-11-08T09:23:16Z

Algorithmic sets and Notifications

← Nächstältere Version		Version vom 8. November 2014, 09:23 Uhr
Zeile 23:		Zeile 23:

	== Algorithmic sets and Notifications ==		== Algorithmic sets and Notifications ==
	* We want to define the receivers of a notification with an algorithmic set.		* <b>We want to define the receivers of a notification with an algorithmic set.</b>
	* This means every Notification has an algorithmic set of receivers attached to it.		* This means every Notification has an algorithmic set of receivers attached to it.
	* How this algorithmic set of receivers is attached is not part of this article.		* How this algorithmic set of receivers is attached is not part of this article.

2014-11-08T09:22:46Z

Algorithmic sets and Notifications

← Nächstältere Version		Version vom 8. November 2014, 09:22 Uhr
Zeile 42:		Zeile 42:
	</pre>		</pre>
	* Every connected client queries its notifications via a REST interface.		* Every connected client queries its notifications via a REST interface.
			* All notifications should be grouped by their NotificationReceiverPredicate instance.
			* So instead of testing the predicate for every notification we only need to test every predicate instance once.
	* ~~If the~~ amount of different ~~algorithmic sets~~ is relatively low ~~(this is often~~ the ~~case), it makes sense~~ to ~~group~~		* The amount of different predicate instances is relatively low, so we should be capable of delivering the notifications to a client reasonable fast.

2014-11-08T09:18:00Z

Algorithmic sets and Notifications

← Nächstältere Version		Version vom 8. November 2014, 09:18 Uhr
Zeile 34:		Zeile 34:
	}		}
	</pre>		</pre>
			* Practically the above tupel, will be part of the session, but it seems reasonable not to use the session directly for a cleaner interface.
	* So the Predicate for Notification receivers would have the form:		* So the Predicate for Notification receivers would have the form:
	<pre>		<pre>

2014-11-08T09:14:47Z

← Nächstältere Version		Version vom 8. November 2014, 09:14 Uhr
Zeile 17:		Zeile 17:
	* This approach is only reasonable if all tested elements are in memory, querying them from a database would be at least suboptimal.		* This approach is only reasonable if all tested elements are in memory, querying them from a database would be at least suboptimal.

			== Logical Groups ==
			* For predicate aggregation we could simply implement PredicateCollections.
			* PredicateCollectionOr<T>
			* PredicateCollectionAnd<T>

	== Algorithmic sets and Notifications ==		== Algorithmic sets and Notifications ==

2014-11-08T09:12:07Z

Algorithmic sets and Notifications

← Nächstältere Version		Version vom 8. November 2014, 09:12 Uhr
Zeile 28:		Zeile 28:
	public User getUser(); // Including the role.		public User getUser(); // Including the role.
	... // Will grow in the future.		... // Will grow in the future.
			}
			</pre>
			* So the Predicate for Notification receivers would have the form:
			<pre>
			public interface NotificationReceiverPredicate extends Predicate<ConnectedClientTupel>
			{
	}		}
	</pre>		</pre>
	* Every connected client queries its notifications via a REST interface.		* Every connected client queries its notifications via a REST interface.


	* If the amount of different algorithmic sets is relatively low (this is often the case), it makes sense to group		* If the amount of different algorithmic sets is relatively low (this is often the case), it makes sense to group