expand_less
My thoughts about notifications are along these lines. When you publish to a circle (could also use "membrane" term, but let's stick with circle in our design), this will be in the context of a publisher implementation (the system, not just the agents who publish through it), so that implementation handles all of that.
There will be a static and dynamic concept here, the publishing system will maintain a static view for any circles it supports locally as well as provide all the options for dynamic actions (notifications via email, twitter, whatever). Our reference implementation will have some set of supported protocols and methods, and ODC networked implementations can do these and/or some others they need for their users.
There should also be efficient protocols for networked servers to keep each others circles in sync, but in principle each participant only needs to worry about the circles they are in.
--[[Gerry]].....2017-03-03 14:41:27 UTC
Thinking about some details. I think we need to dig into the different agents and how they get instantiated.
Pragmatically, we will have a network of ODC calendar instances, and we need some way(s) for the instances to know about each other and communicate. I'm thinking there should not be a fundamental difference between an instance associated with a large organization or a personal instance on a smart phone. Being a publishing instance will probably commit you to respond to certain requests as long as you have any published events in play.
I think we can just say that authentication and identity of circle owners and publishers is up to the overall calendar application. Circle membership and identifying participants and resources doesn't have to be closed. If it is, it can be fully internal to the app, but if it is open you can use open invitation with RSVP protocols.
We will want to put our attention on the open cases, but fully support organizations with different needs. Most of the time they will need both the open protocols and closed ones they are required to use.
--[[Gerry]].....2017-03-05 13:08:30 UTC
My thoughts about notifications are along these lines. When you publish to a circle (could also use "membrane" term, but let's stick with circle in our design), this will be in the context of a publisher implementation (the system, not just the agents who publish through it), so that implementation handles all of that.
There will be a static and dynamic concept here, the publishing system will maintain a static view for any circles it supports locally as well as provide all the options for dynamic actions (notifications via email, twitter, whatever). Our reference implementation will have some set of supported protocols and methods, and ODC networked implementations can do these and/or some others they need for their users.
There should also be efficient protocols for networked servers to keep each others circles in sync, but in principle each participant only needs to worry about the circles they are in.
--[[Gerry]].....2017-03-03 14:41:27 UTC
Thinking about some details. I think we need to dig into the different agents and how they get instantiated.
Pragmatically, we will have a network of ODC calendar instances, and we need some way(s) for the instances to know about each other and communicate. I'm thinking there should not be a fundamental difference between an instance associated with a large organization or a personal instance on a smart phone. Being a publishing instance will probably commit you to respond to certain requests as long as you have any published events in play.
I think we can just say that authentication and identity of circle owners and publishers is up to the overall calendar application. Circle membership and identifying participants and resources doesn't have to be closed. If it is, it can be fully internal to the app, but if it is open you can use open invitation with RSVP protocols.
We will want to put our attention on the open cases, but fully support organizations with different needs. Most of the time they will need both the open protocols and closed ones they are required to use.
--[[Gerry]].....2017-03-05 13:08:30 UTC