Closed shilpa-padgaonkar closed 2 months ago
Hello @shilpa-padgaonkar
As multiple type is managed in another thread I'm not sure to understand how filters
can be used.
Let's consider UC as the one we have in Device location about initial event.
In this case should be consider instead the config
part?
In order to discuss on an existing case, if we try to realign our subscription model to CloudsEvent one we are going from:
{
"webhook": {
"notificationUrl": "https://application-server.com",
"notificationAuthToken": "c8974e592c2fa383d4a3960714"
},
"subscriptionDetail": {
"device": {
"phoneNumber": "123456789"
}
},
"area": {
"areaType": "CIRCLE",
"center": {
"latitude": 50.735851,
"longitude": 7.10066
},
"type": "org.camaraproject.geofencing.v0.area-entered"
},
"subscriptionExpireTime": "2024-06-08T09:42:23.807Z",
"subscriptionMaxEvents ": "1",
"initalEvent ": true,
"subscriptionId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"startsAt": "2024-03-08T09:42:23.807Z",
"expiresAt": "2024-06-08T09:42:23.807Z"
}
}
to
{
"id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"protocol": "HTTP", **Only HTTP
"protocolSettings": {},
"sink": "https://application-server.com",
"sinkCredential": { **To be studied
"credentialType": "OauthToken"
"credential": "c8974e592c2fa383d4a3960714"
},
"types": [ **depending on other discussion if 1 or *
"org.camaraproject.geofencing.v0.area-entered"
],
"config": {
"subscriptionDetail": {
"device": {
"phoneNumber": "123456789"
},
},
"area": {
"areaType": "CIRCLE",
"center": {
"latitude": 50.735851,
"longitude": 7.10066
},
"type": "org.camaraproject.geofencing.v0.area-entered"
},
"subscriptionExpireTime": "2024-06-08T09:42:23.807Z",
"subscriptionMaxEvents ": "1",
"initalEvent ": true,
"startsAt": "2024-03-08T09:42:23.807Z",
"expiresAt": "2024-06-08T09:42:23.807Z"
} }
Is it the approach that you looking for?
But even with this approach we need to 'standardise' key word as intialEvent
right?
@bigludo7 Sorry, I didn't realize that you did not want an example with multiple types. If you have already added the initialEvent in config, then you wouldn't need a filter for it again.
May be an example with subject might be useful. Let me see if I can prepare one.
decision to not use filters at least for the first meta release
Problem description We currently do not have a way to allow event consumers to subscribe to very "specific" events unless we create (very specific) distinct event types. Filters (as defined in CloudEvents subscription spec allow for subscriptions to specify that only a subset of events are to be delivered to the sink based on a set of criteria. The filter property in a subscription is a set of filter expressions, where each expression evaluates to either true or false for each event generated. The filter-dialects indicate which filter expression language is supported by event producers.
Possible evolution Camara subscriptions could agree to support filters for subscriptions. I have shown 2 (abstract) examples below which make use of extension-context-attributes (for eg. status_types) and then use it in filter expressions:
Alternative solution
Additional context
149