Add initialEvent management in subscription

[bigludo7]

Problem description Hello, one more on subscription. Looking to define a standard behavior within our implementations. If we got a suscription for geofencing area-entered event type for a device already present in the geo zone, or for roaming-on for a mobile already in roaming mode what is the pattern to adopt ?

To make it generic, if we have a subscription for a given "thing" and the target of this subscription is already in this situation do we trigger an event?

Possible evolution Proposal from the Device location team:

• add in the subscription a initialEvent attribute. If set to true, if the subscription request (when it's managed by the server) matches current device situation an event is triggered. This is commented in details here https://github.com/camaraproject/DeviceLocation/issues/124

Alternative solution Other Pattern

Additional context Issue valid at least for device location & device status

[jlurien]

fyi @PedroDiez

[shilpa-padgaonkar]

@bigludo7 : My 2-cents on this issue: The new requirements around configuration and filters for subscriptions will keep coming even more frequently as we now have api subprojects that focus on connectivity insights etc. Not all subprojects will need every of these configs and filters.

I would hence recommend taking a brief look at both ideas presented here (though wip)

https://github.com/cloudevents/spec/blob/main/subscriptions/spec.md#filters and https://github.com/cloudevents/spec/blob/main/subscriptions/spec.md#config

and see if at least the core idea can be reused in Camara as this will also allow API subprojects to have config keys and filters which are very specific to them, and we could also have common ones when most API subprojects find them useful.

[bigludo7]

Hello @shilpa-padgaonkar Thanks for the sharing. For me it looks a bit complex - for exemple the use of attributes config or filter seems not trivial but perhaps this is my lack of expertise with CloudEvents subscription. What is also the maturity of this specification ? This is still a 0.1 wip version with an update 4 months ago.

But also I understood that it not (yet) too late to change our subscription model so the point you raised is very fair.

In order to progress on this and separate topic, could we Shilpa have a separate issue to discuss this (Migrate or not to CloudEvent subscriptions model) and get feedback from our community ? We can reference you post in a new issue. WDYT?

[shilpa-padgaonkar]

@bigludo7 : I am not insisting on migrating to Cloudevents subscription spec. Like I myself have mentioned earlier in my comment that I am aware it is still wip. I was hoping we could come up with a pattern that uses the core idea proposed in this Cloudevents subscription model regarding configs and filters and see if we can apply those (if needed in a simpler way) for our requirements in Camara (and with no intention to block your changes). I will try to prepare some content in this regard in the next days. Also thanks for suggesting the separate issue point. Sounds good to me

[shilpa-padgaonkar]

@bigludo7 : @rartych pointed out a similar discussion happening currently in device location https://github.com/camaraproject/DeviceLocation/issues/138#issuecomment-1894191964

[bigludo7]

Hello @shilpa-padgaonkar I'm part of this project and at the origin of this one. This one is a bit distinct because it is about the granularity of the event type. As of now we we have for geofencing event for device-entered and for device-left. Working with developers we got feedback to have one type covering both... something like device-left-or-entered.

Back to the topic of the initialEvent I got your point and yes probably without fully align with CloudsEvents subscription we can leverage this specification and use for example the config pattern.

I mean that we can add a config attribute in our model and within we can insert key/value pair. If we do that I'm wondering if we should also add in config other attribute as subscriptionExpireTime.

As you proposed to prepare some contents I let you draft some proposal and happy to contribute & help.

[shilpa-padgaonkar]

Thanks as always @bigludo7 for your offer to contribute and help :) I will create a new issue & add content there.

[jlurien]

Hi, wrt the topic here, I think that we can split defining a new property for the use case (initialEvent) and then discussing where this parameter is to be conveyed in the subscription model. If we follow the CloudEvents subscription model (wip), it seems to me that config would be the placeholder, but first discussion would be if we move that model, as it has other implications, as for example allowing subscription to multiple event types in one request.

[shilpa-padgaonkar]

yes first a new issue will be created to discuss if we need the new model or not.