Tasks #223
Tasks #240: Refactor C++ Implementation to 2011-04-13 Domain Model
Model implementation of Methods according to the domain model
Status: | Resolved | Start date: | 03/02/2011 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | J. Wienke | % Done: | 100% | |
Category: | C++ | |||
Target version: | - |
Description
Do we want to support action attributes (INSERT, UPDATE, QUERY, REQUEST, REPLY, ...) as a general feature of RSB events or do we decide that this is domain specific data?
Associated revisions
prepare to have a method for events.
refs #223
prepare to have a method for events.
refs #223
matching of methods
fixes #223
History
#1 Updated by J. Wienke about 13 years ago
This implies that there is some kind of state, which isn't- So I don't think that it is a good idea. The only thing that could also have a meaning without state would be UPDATE as a refinement of an older message. But I got the suspicion that this leads to a general misuse of this pattern and is used then more often than generally useful. So better not ;)
#2 Updated by J. Otto about 13 years ago
But with action attributes a component is able to hold his own "state" (;
#3 Updated by J. Wienke about 13 years ago
Jens Otto wrote:
But with action attributes a component is able to hold his own "state" (;
What do you mean?
#4 Updated by S. Wrede about 13 years ago
Well, I am not entirely convinced by Johannes initial argument. Sure, some (most) of the RSB interactions don't feature state. However, the applications using RSB do so. Why not help developers by adding this kind of information and accompanying filters to the feature set of the framework. In my opinion the alternative for developers is to (a) explicitly represent this either in user-defined event types or (b) in the content of events. (a) may lead to a bloated type hierarchy and (b) to performance penalities as you are parsing complex payload for metadata access. Furthermore, I suspect that we could use it also internally for the patterns that we want to offer as part of the basic functionality.
BTW: Ich geh' jetzt ins Bett und wir können das auch morgen direkt besprechen... ;-)
#5 Updated by J. Wienke almost 13 years ago
- Subject changed from Discuss Action Types for Events to Model implementation of Methods according to the domain model
- Category changed from Protocol to C++
- Assignee deleted (
S. Wrede)
We have decided on a version how to perform this. This is described in the domain model. Now a model for the implementation is required.
#6 Updated by J. Wienke almost 13 years ago
- Parent task set to #240
#7 Updated by J. Wienke almost 13 years ago
- Status changed from New to In Progress
- Assignee set to J. Wienke
#8 Updated by J. Wienke almost 13 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset r830.