Tasks #223

Tasks #240: Refactor C++ Implementation to 2011-04-13 Domain Model

Model implementation of Methods according to the domain model

Added by S. Wrede about 13 years ago. Updated almost 13 years ago.

Status:ResolvedStart date:03/02/2011
Priority:NormalDue 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

Revision 0a180a84
Added by J. Wienke almost 13 years ago

prepare to have a method for events.

refs #223

Revision cca59169
Added by J. Wienke almost 13 years ago

prepare to have a method for events.

refs #223

Revision 3fd0a88f
Added by J. Wienke almost 13 years ago

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.

Also available in: Atom PDF