You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To guide what gateway infrastructure we need, it might be useful to start with what APIs we would like to be able to use at the application layer. These APIs would likely be the top layer in a cloudcomm-like system, where the running application offloads data to a gateway subsystem. That gateway library ("gwlib") would then likely store the data until it can offload it to a gateway, which would then forward the data on somehow. Now, there are quite a few different designs that could work here.
Some thoughts:
1. Something simple
Setup a URL at boot and then just write data. The endpoint at the given URL will get HTTP posts with the data.
This makes gwlib also capable of storing the data. Each create() creates a "file" which can then be removed after it is offloaded or kept until delete() is called.
Instead of a log-type abstraction, what about an HTTP-like abstraction? This would let the app issue HTTP POSTs that, when a gateway was in contact, would be issued by the gateway, with a callback being called when the POST completed. This provides a lot more flexibility, but does change the abstraction.
To guide what gateway infrastructure we need, it might be useful to start with what APIs we would like to be able to use at the application layer. These APIs would likely be the top layer in a cloudcomm-like system, where the running application offloads data to a gateway subsystem. That gateway library ("gwlib") would then likely store the data until it can offload it to a gateway, which would then forward the data on somehow. Now, there are quite a few different designs that could work here.
Some thoughts:
1. Something simple
Setup a URL at boot and then just write data. The endpoint at the given URL will get HTTP posts with the data.
2. More like files:
This makes gwlib also capable of storing the data. Each
create()
creates a "file" which can then be removed after it is offloaded or kept untildelete()
is called.3. The HTTP option
Instead of a log-type abstraction, what about an HTTP-like abstraction? This would let the app issue HTTP POSTs that, when a gateway was in contact, would be issued by the gateway, with a callback being called when the POST completed. This provides a lot more flexibility, but does change the abstraction.
Others?
There are many possibilities for this, and these are certainly not all of them. What would be most useful for you?
The text was updated successfully, but these errors were encountered: