* Additional attributes for band_type, band_status, concert_count, add_new_members, play_commitment, touring_option, paid_gigs, hourly_rate, gig_minimum * For joined table musician_instruments, remove the hard requirement that they be joined to a user, rather a “player” that is polymorphic. * For joined table performance_stamples, remove the hard requirement that they be joined to a user, rather a “player” that is polymorphic. * For joined table online_presences, remove the hard requirement that they be joined to a user, rather a “player” that is polymorphic. * Change models as appropriate with new attributes and modify belongs_to / has_many directives as necessary. * Fix existing usages of user_id to work with polymorphic player_id. * Fix tests that use user_id * Add new tests that exercise online_presence, performance_samples, and instruments that target a band, rather than a user. |
||
|---|---|---|
| .. | ||
| bin | ||
| config | ||
| features | ||
| lib | ||
| log | ||
| script/package | ||
| spec | ||
| .gitignore | ||
| .pg_migrate | ||
| .ruby-gemset | ||
| .ruby-version | ||
| .simplecov | ||
| Gemfile | ||
| Guardfile | ||
| README.md | ||
| Rakefile | ||
| build | ||
| jam_websockets.gemspec | ||
| jenkins | ||
| migrate.sh | ||
README.md
TODO & DESIGN LIMITATIONS
-
!!!! lock up multi-threaded unsafe data structures
-
The rabbitmq connection isn't pooled. Throughput limitation (but could be resolved by just starting more instances of JamWebsocket behind Haproxy)
-
The database connection isn't pooled. Throughput limitation (but could be resolved by just starting more instances of JamWebsocket behind Haproxy)
-
We make just one user topic registration and session registration for all users/sessions. If ever we had 10 of servers, it could be wasteful. It just depends on how fast the bogus messaging can be ignored
-
The database connection is pooled.
-
The user model is stored in memory, meaning periodically it should be reloaded from the database (in case a user was marked inactive and you want them knocked out of the system)
-
The user could easily join to multiple sessions. Currently, though, the ClientContext object only tracks one jam session topic subscription. This is minimial to change.
-
peek logic not implemented on server for protoc messages; this could be done to save cost of deserialization and serialization for session/user directed messages