currently, this would result in the user seeing a MOD followed by a NEW. maybe that's no problem. in that case MOD vs NEW seems a useless thing to distinguish, and we ought not provide this semantic. if it is useful, we need to avoid this. we don't want to just drop the MOD. either we could present the MOD as a NEW, and drop the dump result, or we can hold the MOD until we get the dump result, and then send them both.
this last seems a lot of state for not much value. i say we pass along the MOD and drop the dump result. simply failing to distinguish means that we would send the MOD followed by the NEW, meaning the user possibly ends up with stale state. there are orderings where the NEW would have more up-to-date information than a MOD that came before it, but all such situations seem to require a change following our request for a dump, which will generate a new MOD event with the up-to-date information.
so i think the way forward is:
eliminate the mod vs new distinction, there is only "event" and "delete event"
** this has other benefits regarding dropped messages and the weird semantics of "new" for devices that existed before we started
pass along all MOD messages
only pass along dump messages if we've never seen a message about this device
to be completely robust, this last line (filter dumps if we've sent a message about this device) need to take into account delete events. consider this ordering:
subscribe to events
request dump
dump is filled in
device is deleted, we get delete event about unknown device
dump is returned, we get event about device that no longer exists
this is solved by treating DEL exactly like MOD for purposes of dump response handling, though it does require some annoying state we wouldn't otherwise need (to track deleted objects, at least up through the dump response).
a lot of effort to handle race conditions on initialization :(. gotta do it, though.
Imagine the following interleaving:
currently, this would result in the user seeing a MOD followed by a NEW. maybe that's no problem. in that case MOD vs NEW seems a useless thing to distinguish, and we ought not provide this semantic. if it is useful, we need to avoid this. we don't want to just drop the MOD. either we could present the MOD as a NEW, and drop the dump result, or we can hold the MOD until we get the dump result, and then send them both.
this last seems a lot of state for not much value. i say we pass along the MOD and drop the dump result. simply failing to distinguish means that we would send the MOD followed by the NEW, meaning the user possibly ends up with stale state. there are orderings where the NEW would have more up-to-date information than a MOD that came before it, but all such situations seem to require a change following our request for a dump, which will generate a new MOD event with the up-to-date information.
so i think the way forward is:
to be completely robust, this last line (filter dumps if we've sent a message about this device) need to take into account delete events. consider this ordering:
this is solved by treating DEL exactly like MOD for purposes of dump response handling, though it does require some annoying state we wouldn't otherwise need (to track deleted objects, at least up through the dump response).
a lot of effort to handle race conditions on initialization :(. gotta do it, though.