adjust the related RfC "SystematicMetadata"
There is a long-standing RfC which basically describes the same idea on a much wider, conceptual scope. Indeed I consider this approach used here for solving the problem with GUI uptades also as a proof of concept, to be expanded to a much wider scope in case it works out well. The new insight here is, that, by transferring a diff in pull mode, we can circumvent the architectural problems with typing, which showed up quite clearly in earlier design studies towards this concept. The change from push to pull is by far not so fundamental as it looks, since the sender still may initiate the exchange by sending a message offering the diff iterator for the receiver to pull. This way, we get a handshake and still sustain the crucial part, which is to decouple the data representation and give the receiver full control over the interpretation of the exchanged data.
This commit is contained in:
parent
b051845835
commit
f90e9c7bbd
1 changed files with 7 additions and 5 deletions
|
|
@ -33,11 +33,13 @@ to span the whole virtual model, and thus there never needs to be an universal
|
|||
model data structure definition. Data structure becomes implementation detail.
|
||||
|
||||
Parts of the system talk to each other by _describing_ some subtree of metadata.
|
||||
This description is _always pushed:_ the receiver implements an API allowing the
|
||||
sender to navigate to some path-like scope and populate it with values, similar
|
||||
to populating a filesystem. It is up to the receiver to assemble these information
|
||||
into a suitable representation. Some receiver might invoke an object factory, while
|
||||
another serialises data into an external textual or binary representation.
|
||||
This description is transferred _in the form of a tree diff:_ the receiver pulls
|
||||
a sequence of diff verbs from a diff iterator, and interpreting these verbs will
|
||||
walk him down and expand the tree in question. Sub-scopes are ``opened'' and
|
||||
populated, similar to populating a filesystem. It is up to the receiver to
|
||||
assemble these information into a suitable representation. Some receiver
|
||||
might invoke an object factory, while another serialises data into an
|
||||
external textual or binary representation.
|
||||
|
||||
|
||||
Abstract Metadata Model
|
||||
|
|
|
|||
Loading…
Reference in a new issue