/ doc / DocFrag / ARCCore.ClientUpdatePosition / Attribute

Attribute

Edit keys at this level only

AssemblyName = ARCCore
ClassNamespace = ARCCore
ClassType = ClientUpdatePosition
Description = Describes from WHERE (from WHEN) in the historic -PropertyStream- new data is to be returned.0x000D0x000A(or actually, it describes up to which point in time client already has updated data).0x000D0x000A0x000D0x000ACommunicated between client and server as follows:0x000D0x000A0x000D0x000A1) At initialization of -ActualConnection-:0x000D0x000ASent by client to server in order to inform the server about the client's update status.0x000D0x000A0x000D0x000A2) For every new -PropertyStreamLine- sent from server to client:0x000D0x000ASent by server to client. Done by prepending to the -PropertyStreamLine- being sent, with '::' (double colon) as a separator.0x000D0x000AExplains from where in the -PropertyStream- this line originated.0x000D0x000AThe server also keeps track of the last value sent to the client as long as the -ActualConnection- is active.0x000D0x000A0x000D0x000AUsed in connection with -Subscription- which describes WHAT data is required from the -PropertyStream-.0x000D0x000ATODO: Clarify difference between -ClientUpdatePosition- and -FromTime- / -ToTime-.0x000D0x000A0x000D0x000ATODO: Build revision number into this? (-DataRetention- or keep in filename?0x000D0x000A0x000D0x000ATODO: Ensure that the format being used suits the encoding mechanism well (see EncodeValuePart) (no special encoding should be necessary as want a human readable format also after encoding)0x000D0x000A0x000D0x000ADescribes status of a client's up-to-date level.0x000D0x000ANote that client in this case not only means -Client- but any -ARNodeType-.0x000D0x000Ar0x000AExamples:0x000D0x000A0x000D0x000A1) 'ClientDatastoreIsEmpty' (see -ClientDatastoreIsEmpty-).0x000D0x000A0x000D0x000A2) 'OnlyNewDataIsRequested' (see -OnlyNewDataIsRequested-).0x000D0x000A0x000D0x000A3) 'GoBack|1000' (see -IsGoBack-) means start from 1000 elements back.0x000D0x000A0x000D0x000A4) 'StorageFile0042|42042': The common scenario. Last update was index 42042 in 'StorageFile0042', next update should be at least 42043 (or index 0 in next file)0x000D0x000A0x000D0x000AAn 'IsEndOfStream' marker may be added, like this:0x000D0x000A'StorageFile0068|42042042|IsEndOfStream' (see -IsAtEndOfStream-).0x000D0x000A0x000D0x000AThis class is immutable.0x000D0x000A
Interfaces = ITypeDescriber0x003BIEquatable0xoooo003CClientUpdatePosition0xoooo003E
InterfacesDirectlyImplemented = ITypeDescriber0x003BIEquatable0xoooo003CClientUpdatePosition0xoooo003E
LongDescription = 0x000D0x000ATODO: Note how we assume that if we have multiple outgoing connections, that is, if we0x000D0x000ATODO: have multiple CoreDB's to choose from, they are all compatible regarding clientUpdateStatus.0x000D0x000ATODO: This would probably not be the case with how clientUpdateStatus is built up today0x000D0x000ATODO: (Apr 2020) with filename + index.0x000D0x000ATODO: Consider adding timestamp, actual property line or similar, in order for different CoreDB instances to more TODO: accurately decide from where to 'pick-up' from when receiving a new incoming connection with a subscription request.TODO: OR, alternatively, ensure that CoreDB instances coordinate among themselves so that they always have the exact same TODO. storage-layout (having a master instance at any given time for instance).0x000D0x000A0x000D0x000ATODO: If we add timestamp, it can then be up to the client to keep track of it, by 'listening' to Timestamps / 'Heartbeats' inserted in the TODO: property stream. The client can then transmit it to the server, as a backup, in case the ordinary filename + index TODO: information makes no sense. Using only Timestamp would of course lead to some overlap (duplicate property stream lines being sent), TOOD: since it is probably quite coarse.0x000D0x000ATODO: Other ideas for keeping clients correctly in sync:0x000D0x000ATODO: Server can inject the current position at regular intervals in the property stream. This serves the same purpose as injecting a TODO: Timestamp / 'Heartbeat' but the position becomes exact instead of approximate. When the client understands that there is someTODO: corruption present, it can look for the last such value, delete stored data after that position, and update from server from this TODO: exact known position. (actually the client can inject the position itself, since it receives the position with any value sent)

Edit keys at all sub levels.
NOTE: Edits are always additive. Use 'Invalid' in order to delete keys.

Edit single sub keys only: AssemblyName / ClassNamespace / ClassType / Description / Interfaces / InterfacesDirectlyImplemented / LongDescription

Generated 2024-06-02 12:08:58.713 UTC