QuintinWillison
commented
2 years ago I wonder if this might be a reason for us to consider the create of an AAT publishing SDK (or SDKs 😉) for backend use, where the user brings their own stream of locations... My gut says Node.js, but Golang and Python would also be contenders.
In order to support A/B testing and testing features on a fraction of the whole user base of an app, we could provide a way to send locations to subscribers from other sources and make them look as if they've come from an AAT publisher.
Now, if some users will try and adopt AAT in their app they probably won't try our feature on all the users. Instead, this will be done gradually, which leads to the issue that there might be a subscriber using AAT but the rider not using it. Therefore, the subscriber either will not show anything (which is bad UX) or it would have to detect that the other side is not using AAT and fallback to another solution. This is not ideal as the subscriber should not know those details and switching between different solutions might be difficult to implement and adds complexity to the project.
Therefore, we could provide some kind of a script or a small program that could take in locations, convert them to AAT's location updates and send them via a channel to the subscriber. The program should also join the presence and do other things that a normal publisher would do in order to keep the UX of the subscriber as close to the real publisher as possible.
┆Issue is synchronized with this Jira Uncategorised by Unito