In Ringside clients we have multiple "channels" to talk to different servers. In the initial implementation, this was a little kludgy and would just overwrite the client configuration when we talked to a different channel. It would probably be good if we had a formal concept of a channel that we could use across all languages. It would include at least:
1) Server URL
2) Session Key
Note that when an application calls getSessionKey, the server will return data that will need to be updated in the channels that match the session. Also, if a user specifies a session key on initialization, that session key should NOT be rewritten, no matter what (one use case here is the use of infinite session keys).
If we implement clients as collections of channels with one as the default channel, we can then let users create a channel manually or possibly use a factory method to create channels inside the client. The client can then have routing rules that will let it just pick up a channel and execute "call_method" (or the equivalent).
Jason Kinner - 03/Apr/08 08:58 AM Recommendation:
In Ringside clients we have multiple "channels" to talk to different servers. In the initial implementation, this was a little kludgy and would just overwrite the client configuration when we talked to a different channel. It would probably be good if we had a formal concept of a channel that we could use across all languages. It would include at least:
1) Server URL
2) Session Key
Note that when an application calls getSessionKey, the server will return data that will need to be updated in the channels that match the session. Also, if a user specifies a session key on initialization, that session key should NOT be rewritten, no matter what (one use case here is the use of infinite session keys).
If we implement clients as collections of channels with one as the default channel, we can then let users create a channel manually or possibly use a factory method to create channels inside the client. The client can then have routing rules that will let it just pick up a channel and execute "call_method" (or the equivalent).
Jason Kinner - 03/Apr/08 11:29 AM Oddly enough, this is how the Facebooker Ruby client is basically constructed. Might be worth a deeper look at their architecture during design.
In Ringside clients we have multiple "channels" to talk to different servers. In the initial implementation, this was a little kludgy and would just overwrite the client configuration when we talked to a different channel. It would probably be good if we had a formal concept of a channel that we could use across all languages. It would include at least:
1) Server URL
2) Session Key
Note that when an application calls getSessionKey, the server will return data that will need to be updated in the channels that match the session. Also, if a user specifies a session key on initialization, that session key should NOT be rewritten, no matter what (one use case here is the use of infinite session keys).
If we implement clients as collections of channels with one as the default channel, we can then let users create a channel manually or possibly use a factory method to create channels inside the client. The client can then have routing rules that will let it just pick up a channel and execute "call_method" (or the equivalent).