History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: RS-170
Type: Design Design
Status: Open Open
Priority: High High
Assignee: Mark Lugert
Reporter: Rick Saxton
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Ringside Social App Server

Design client framework - same level of support across all clients

Created: 30/Mar/08 11:07 AM   Updated: 07/Apr/08 11:27 PM  Due: 11/Apr/08
Component/s: Client
Affects Version/s: 1.0 GA
Fix Version/s: 1.0 GA

Time Tracking:
Not Specified


 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
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.


Always available at