Stream: implementers
Topic: SubscriptionChannelType
Jens Villadsen (Jun 11 2019 at 13:08):
any chance that the use of SubscriptionChannelType on Subscription could be made extensible? without it being extensible its harder to make custom subscription mechanisms that delivers content beyond the few that are specified in the current required valueset
Josh Mandel (Jun 11 2019 at 14:24):
We're looking at an overhaul of Subscription, draft at at http://build.fhir.org/branches/argo-subscription/subscription -- this kind of extensibility seems like a good thing to include.
Josh Mandel (Jun 11 2019 at 14:25):
(though some features will only apply for specific channel types -- like a handshakes for example, or payload content types. I'm not sure how to document this kind of thing properly/fully.)
Isaac Vetter (Jun 11 2019 at 16:39):
@Jens Villadsen , if you don't mind my asking -- what are the channels you're interested in? Would you expect that the payload options would be restricted per these add'l channels?
Jens Villadsen (Jun 11 2019 at 19:39):
(though some features will only apply for specific channel types -- like a handshakes for example, or payload content types. I'm not sure how to document this kind of thing properly/fully.)
I even more like your proposal here: https://docs.google.com/document/d/1rjOI49M-PBVDT7DpLT9LolV4e3qNU1jZbBKdxTwtRE8/edit#heading=h.9s4dxn3hka2y as it involves previous value
Jens Villadsen (Jun 11 2019 at 19:47):
Jens Villadsen , if you don't mind my asking -- what are the channels you're interested in? Would you expect that the payload options would be restricted per these add'l channels?
@Isaac Vetter I don't mind ;) - I can't see why the current valueset needs such restrictions as the current one's. With @Josh Mandel argo-proposal it more and more starts to resemble queues, which is why I would find it intuitive to use eg. jms, kafka, rabbitmq, RFC 1149, or whatever. Right now that would require extensions instead of a more open valueset? Why the current scoped limitation?
Isaac Vetter (Jun 11 2019 at 20:30):
(I was expecting your response to be something like Server Sent Events or SignalR or even XMPP). Where's the line between asking a FHIR server to push to a queue and messaging?
Jens Villadsen (Jun 13 2019 at 21:01):
SignalR, Server Sent Events or XMPP are also most welcome ;)
Jens Villadsen (Jun 13 2019 at 21:02):
@Isaac Vetter good question.
Jens Villadsen (Jun 13 2019 at 21:16):
But really - at what point should the subscription channel type stop? I believe it should be more flexible, allowing custom protocols without bending it. Also, I can only imagine that the types SMS and Email are useful if some custom logic is build around the server, where it applies either specific templates or alike to resources or that those templates are specified as extensions by the client in the moment of creation
Last updated: Apr 12 2022 at 19:14 UTC
