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
Currently, the Giganto Publish API defines multiple types of requests based on the NodeType of the client. This presents a problem where different clients, like Hog and REconverge, may need to send the same type of request. Currently, they can't do so because their NodeType might not permit it. This leads to inefficiency and lack of flexibility in request management.
I propose refactoring the publish API such that each request has its own request type, decoupling the ability to send specific requests from the client's NodeType. This would allow us to process each request according to its request type rather than the client's NodeType.
By doing this, NodeType becomes unnecessary for defining request handling, enabling each client to send any kind of request they find necessary. This promotes flexibility, efficiency, and ensures that all clients can utilize all the capabilities of the API.
Note:
One alternative might be to allow more NodeType definitions, but this would only make the system more complex and doesn't solve the underlying problem that the current setup is limiting clients' capabilities based on their node types.
The text was updated successfully, but these errors were encountered:
Currently, the Giganto Publish API defines multiple types of requests based on the
NodeType
of the client. This presents a problem where different clients, like Hog and REconverge, may need to send the same type of request. Currently, they can't do so because theirNodeType
might not permit it. This leads to inefficiency and lack of flexibility in request management.I propose refactoring the publish API such that each request has its own request type, decoupling the ability to send specific requests from the client's
NodeType
. This would allow us to process each request according to its request type rather than the client'sNodeType
.By doing this,
NodeType
becomes unnecessary for defining request handling, enabling each client to send any kind of request they find necessary. This promotes flexibility, efficiency, and ensures that all clients can utilize all the capabilities of the API.Note:
One alternative might be to allow more
NodeType
definitions, but this would only make the system more complex and doesn't solve the underlying problem that the current setup is limiting clients' capabilities based on their node types.The text was updated successfully, but these errors were encountered: