Upon subscribe, receive last event published

[oberstet]

Say we are subscribed to on_worker_starting. Upon receiving that event, we are immediately subscribing to on_worker_component_starting.

Fine. However, the component within the worker might get started (and hence the on_worker_component_starting published) fast than we are able to subscribe. Then we "miss" the event.

[oberstet]

The router needs to remember the last event published to some topic in memory. When a client subscribes to the topic with the option receive_last == true, the router subscribes the client as normally, but then sends the last published event to the specific client subscribing (not all currently subscribed clients). The event delivered will have the detail flag last_received == true and received = "2014-12-26T13:22:09Z183". This event is guaranteed to be the first event delivered under the subscription (before any event being delivered under normal operation). When the router has no last event available (either because there wasn't any event published to the topic ever, or the router did not store the last event for that topic), an event with empty payload is send (that is having flags last_received == true and received = current time.

A router may provide means to configure whether a given URI or set of URIs should be enabled for storing the last event published to a topic with an URI matching.

[jjmontesl]

When the router has no last event available (either because there wasn't any event published to the topic ever, or the router did not store the last event for that topic), an event with empty payload is send (that is having flags last_received == true and received = current time.

I feel this empty payload message should be optional, otherwise it'd force clients to handle empty payloads even if they can possibly live without that message.

Note: I also think that in some cases users could also prefer to add their own attributes to that message, so I feel this feature would be better handled by, or complimented by an "interceptor" feature as suggested at https://groups.google.com/forum/#!topic/crossbario/LbfbxnSd5YA .

[fresheneesz]

I may be misunderstanding the scenario, but I think the right way to do this would be to subscribe to any events before triggering something would send events. Sending the last event seems like a bad idea to me.

[oberstet]

I may be misunderstanding the scenario, but I think the right way to do this would be to subscribe to any events before triggering something would send events.

Sure - if it is possible in the app.

This feature is more about a client late joining the party. E.g. subscribe to a sensor event, but the sensor was already running when subscribing. Gimme the last event that was published to the topic automatically when subscribing comes in handy..

[ecorm]

This feature is more about a client late joining the party. E.g. subscribe to a sensor event, but the sensor was already running when subscribing. Gimme the last event that was published to the topic automatically when subscribing comes in handy..

In our app, the client uses a getSensorValue RPC to obtain the current reading. It then uses WAMP events to keep the value updated.

[fresheneesz]

This feature is more about a client late joining the party.

Sending the last events doesn't give you any confidence you received all the events you need. What if there were more than one event sent between when you wanted the events and when the subscription actually got registered? Also, what if no event has been sent yet? Then you have an inconsistency where sometimes event listeners have to ignore the first event they get, and sometimes they have to pay attention to it. This will make it much more error prone to write handlers like this.

In short, sending the previous event is both inconsistent and inadequate. Its not a good solution.

The appropriate way to deal with this is to have some kind of timestamp the client sends, indicating that all the events after that timestamp should be sent to it. This is yet another reason to allow arguments to be passed in a call to subscribe #237 . Often its best if this is some kind of token that originated with the server itself. In the example of a sensor on an arduino system or something like that, the arduino could send the client a timestamp of when it turned on, or when the client connected, or whatever. And then the client could say "give me all events created after arduinoStartTime".

[fresheneesz]

Also, this behavior is not appropriate to put into a messaging protocol. This is delving into what messages get sent. It should be entirely up to the application logic what messages get sent and when they get sent. The protocol has no business defining this.

[sehoffmann]

While I see the usecase (we faced the same issues ourselves), I also think, that this should not be part of the protocol itself.

[oberstet]

Closing as implementation defined. Eg Crossbar.io supports both event history and retained messages.

[katreniak]

This retain flag is useful for topics that represent state - like current temperature, http resource. I would like to argue that it is right tool for this abstraction. It avoids non-essential complexity in observer and publisher application logic. I also reduces startup observer latency.

On the other side, retain is pointless for topics that represent edge - like button was pressed. But this is not good reason to kill this feature.

Event history is more generic but also way more complex feature. It is also harder to use for observer to retrieve initial state topic.

For reference, MQTT supports retain flag with exactly this meaning.