Skip to content

Conversation

@giannislelekas
Copy link
Collaborator

Refactored objectID; moved functionality to server side. Every new AtomicState at server side is assigned a static objectId, which is then used as a key to map to the state. The state along with the corresponding id is transferred back and forth between client-server. The id does not change even after an update of a state.

PhilipeLouchtch and others added 8 commits March 24, 2019 16:28
ObjectState is an empty interface and never used other than being extended by AtomicObjectState. RdObject currently is tied to Atomic implementation and I will probably stay that way
trying to separate this work from next commit
Now the object id's are autogenerated on new rdo's and are kept track in the state of the rdo
@PhilipeLouchtch
Copy link
Collaborator

This refactoring doesn't make sense to me. It certainly is not how I intended to interaction of pushing/fetching objects (states of) to be.

Could you please first clearly introduce and motivate the design/approach?

@giannislelekas
Copy link
Collaborator Author

  • currently AtomicObjectState generates, as well as being able to modify the UUID which is assigned to itself. This mainly motivated me for this refactoring.
  • to my belief, the UUID objectId should be static and shouldn't/doesn't have to be visible to an AtomicObjectState. It is instead information that Client-Server objects utilize for exchanging RDOs. Both Clients and Server objects have as field a mapToStates[ObjectId, AtomicObjectState], hence the objectId is the key mapping to the current version of a state regarding a client and the final committed version in the Server.

Is there any particular reason you need this as a method of the AtomicObjectState?

@steffansluis steffansluis removed their request for review January 22, 2021 17:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants