So far, after #1 there are two layers: a back layer that only knows how to translate account credentials to SMS, and a front layer that handles niceties for XMPP-to-XMPP over various back gateways.
There is a goal to provide users with "instant set-up" where they don't get account credentials with some VoiP provider directly, but just rent a phone number directly from "us".
Of course, one could argue that this is simply another back-end. The fact that the VoiP provider is powered by another ("us" by bandwidth AP, for example) is not important to any layer. By this logic, the responsibility for tracking usage and billing status would go to this new back-end which would then talk to the real provider. This sounds like adding billing features to existing back-ends.
However, there is also a valid argument that the "back layer" gateways are nice and simple: they just take credentials of a single kind and translate XMPP to some provider API. Why should they be doing billing tracking? Perhaps the front layer should track usage, but then it also knows too much -- instead of nicely routing to a chosen back end, it becomes all muddled.
One could argue that the billing back-end belongs outside the XMPP scope entirely (as it would if you were using an existing back layer directly), but why would we build non-XMPP APIs just to then translate them to XMPP ourselves?
Since this function seems to belong equally to the back or front layer, and since it seems to complicate either of them in a similar way, one begins to suspect that another layer is needed.
I propose a "billing gateway" which functions (to the appearance of upstream) just like a normal "back end" gateway (XMPP to SMS translator, such as the sgx- projects). It does this translation likely by routing XMPP-to-XMPP and using one of the "actual" sgx- back-layers. It exists to track usage and hide the "true" VoiP provider in use (and any credentials for that provider) from the end user completely. Instead of "registering" with credentials, the user sets up with this gateway billing information and asks it to purchase a number. This set up could happen via in-band registration, an ad-hoc command, a web UI, whatever UX is desired. Once this set up is complete, the "billing gateway" might even configure the "front layer" (cheogram) on the user's behalf to use this new route automatically. In fact, if setup is done from the web UI, cheogram may also be prompted to send a welcome message to the user, or other such things at this time.
So far, after #1 there are two layers: a back layer that only knows how to translate account credentials to SMS, and a front layer that handles niceties for XMPP-to-XMPP over various back gateways.
There is a goal to provide users with "instant set-up" where they don't get account credentials with some VoiP provider directly, but just rent a phone number directly from "us".
Of course, one could argue that this is simply another back-end. The fact that the VoiP provider is powered by another ("us" by bandwidth AP, for example) is not important to any layer. By this logic, the responsibility for tracking usage and billing status would go to this new back-end which would then talk to the real provider. This sounds like adding billing features to existing back-ends.
However, there is also a valid argument that the "back layer" gateways are nice and simple: they just take credentials of a single kind and translate XMPP to some provider API. Why should they be doing billing tracking? Perhaps the front layer should track usage, but then it also knows too much -- instead of nicely routing to a chosen back end, it becomes all muddled.
One could argue that the billing back-end belongs outside the XMPP scope entirely (as it would if you were using an existing back layer directly), but why would we build non-XMPP APIs just to then translate them to XMPP ourselves?
Since this function seems to belong equally to the back or front layer, and since it seems to complicate either of them in a similar way, one begins to suspect that another layer is needed.
I propose a "billing gateway" which functions (to the appearance of upstream) just like a normal "back end" gateway (XMPP to SMS translator, such as the sgx- projects). It does this translation likely by routing XMPP-to-XMPP and using one of the "actual" sgx- back-layers. It exists to track usage and hide the "true" VoiP provider in use (and any credentials for that provider) from the end user completely. Instead of "registering" with credentials, the user sets up with this gateway billing information and asks it to purchase a number. This set up could happen via in-band registration, an ad-hoc command, a web UI, whatever UX is desired. Once this set up is complete, the "billing gateway" might even configure the "front layer" (cheogram) on the user's behalf to use this new route automatically. In fact, if setup is done from the web UI, cheogram may also be prompted to send a welcome message to the user, or other such things at this time.