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
We may have now very many ESMEs in a live system (a count may be > 100). This leads of making of management rather complicated and making of GUI console slow.
Solutions:
as a short-term solution we can make GUI optimization:
a) add a posibility of refresh only one EMSE (not only a whole list)
b) make a whole list refresh and an initial web page filling as a single http request (now we make a separate request per ESME). This demands of updating of a core part and web page
Make ESME structurization as ESME clusters and refactor GUI so it become a structurized one we will see a list of clusters and each cluster can be expanded as a list of ESMEs.
There may be two different approaches there (that contradicts each other):
a) remove a cluster approach and implement #3.
In this case we will have two levels "ESME / SMPP connection channel". Instead of current cluster we will have an ESME, all settings will be made at ESME level. We will have only a state (connected / disconnected) and statistics per an ESME SMPP channel. In this case we do not need #4
b) We leave a culster / ESME approach and do not implement #3. But we need to restructure of ESME configuring by moving of most options into a cluster level (and we will not be able to configure many paramenters per a ESME, we will have a single value per a cluster). In this case we will implement #4 but implementation must be done by introducing of a "cluster" term into a CLI / GUI interfaces and change a structure of GUI making of it 2-leveled: cluster / ESME.
The text was updated successfully, but these errors were encountered:
We may have now very many ESMEs in a live system (a count may be > 100). This leads of making of management rather complicated and making of GUI console slow.
Solutions:
as a short-term solution we can make GUI optimization:
a) add a posibility of refresh only one EMSE (not only a whole list)
b) make a whole list refresh and an initial web page filling as a single http request (now we make a separate request per ESME). This demands of updating of a core part and web page
Make ESME structurization as ESME clusters and refactor GUI so it become a structurized one we will see a list of clusters and each cluster can be expanded as a list of ESMEs.
There may be two different approaches there (that contradicts each other):
a) remove a cluster approach and implement #3.
In this case we will have two levels "ESME / SMPP connection channel". Instead of current cluster we will have an ESME, all settings will be made at ESME level. We will have only a state (connected / disconnected) and statistics per an ESME SMPP channel. In this case we do not need #4
b) We leave a culster / ESME approach and do not implement #3. But we need to restructure of ESME configuring by moving of most options into a cluster level (and we will not be able to configure many paramenters per a ESME, we will have a single value per a cluster). In this case we will implement #4 but implementation must be done by introducing of a "cluster" term into a CLI / GUI interfaces and change a structure of GUI making of it 2-leveled: cluster / ESME.
The text was updated successfully, but these errors were encountered: