lancejpollard
commented
12 years ago I like the idea of having a centralized interface to all things related to the user:
- user record
- authorization (permissions, roles, etc.)
- scopes (records via cursors, etc.)
- socket
- even, potentially, controller instances so tower would only have to instantiate 1 controller per class per user (a small but perhaps useful optimization). There's a few issues with this one though, mainly that we'd have to redo the controller api not to use any instance variables, but to work more like express'
app.use(function(req, res, next))system, which I'm kinda starting to like more than how Rails did it.
At the same time this interface - entry point to the "user" stuff - should be as as simple as possible. But, because the server has multiple users it has to keep track of (whereas the client only has one), we can't make it this simple:
App.user # or App.currentUser
App.socket
# ...because the server would need to wrap that in what you're calling the Tower.NetManager object (currently Tower.NetConnection), so like this:
App.connection.user
App.connection.socketWith that we can also do neat things on the client like wrap those in Handlebars helpers, such as:
Handlebars.registerHelper 'currentUser', ->
# since behind the scenes `App == Tower.Application.instance()`
Tower.Application.instance().connection.user
Handlebars.registerHelper 'currentAbility', ->
Tower.Application.instance().connection.abilityand then in the views do something like this:
{{if currentUser}}
<h1>Welcome {{currentUser.name}}</h1>
<a {{bindAttr logout href=true}}>Logout</a>
{{else}}
<a {{bindAttr login href=true}}>Login</a>
{{/if}}In terms of the class_instances idea, I like this kind of thing and have been thinking a lot about it too, but it seems to be pretty complex to implement and I'm not sure how much benefit we will get out of it (mainly in terms of performance). For the client it makes sense, it's pretty much what we're doing now. But for the server it gets more complicated. Here are some of the issues on the server.
First, for the controllers, we'd have to refactor all the actions to be passed parameters instead of setting request, response, params, headers, etc. to the controller instance, so actions would go from this (current):
# on the server
class App.PostsController extends App.Application
index: ->
App.Post.all (error, posts) =>
@respondWith (format) =>
format.html => @render 'index', collection: posts
format.json => @render json: posts, status: 200to something like this:
# on the server
class App.PostsController extends App.Application
index: (request, response, next) ->
App.Post.all (error, posts) =>
@respondWith (format) =>
format.html => response.render 'index', collection: posts, next
format.json => response.render json: @collection, status: 200, nextThe reason is because if we're going to cache the controller object, then what if the current user sends two async requests, and the second one finishes before the first... If they both go to the same instance and set variables, the state would get messed up. So there can't be any state kept in server-side controllers; everything would need to be passed as arguments like app.use (req, res, next) ->. By implementing that pattern, we stick more closely to express' API, and it is cleaner because we can now cache the controller instances. But at the same time, the API becomes more verbose (we have to manually manage a bunch of common/boilerplate code), and the controller actions start revolving around the request and response objects, rather than the controller itself. This would mean - if we want to keep the API on the client and server pretty consistent - we need to introduce the request object on the client, which isn't really necessary (at least it doesn't seem necessary at the moment).
So then it comes down to, what is the benefit we gain by caching the controller instances on the server per-user? Pretty much, it comes down to performance - we could potentially shave off some milliseconds from the request by not creating a controller instance for each request. But that's all speculation, I haven't tested that. And I'm starting to think that it wouldn't be large enough to sacrifice the simplicity of the current controller action API.
That's my main concern in terms of caching controller instances on a per-user basis.
In terms of models, having a central object for each user/socket/session would not only standardize the way all-things-user get accessed (through some net manager/connection object), but it would also allow us to create an identity map. We could scope all the data for a request to the current "connection", so associations/reflections wouldn't have to reload data that's already loaded. I think that's pretty cool. And we can do that with the current or express-style controller action api (above), so we could leave it the same and still accomplish this.
Those are my main concerns/thoughts for the server.
For the client, we should/can definitely cache everything on a central object, and maybe alias it to App, so:
App.currentUser == App.connection.userOne issue with this is Ember already has ideas on how this stuff should work, so we have to work with/around that. For example, they lazily-instantiate controller instances on the App.router object, and we can't change that (at least it seems). So Tower just aliases App.postsController to App.router.postsController essentially. If we made this work around a "connection" object, then we'd have to take that kind of stuff into account.
In terms of caching Ember.View instances on the client, I like that idea but there are lots of things to consider with that. The benefit of doing this is that if you append a view to the DOM a second time, it doesn't have to rebuild it's own DOM, since it was done the first time. This makes rendering noticeably faster [on some browsers, not Firefox or IE it seems though, where it doesn't even matter]. The main issue with this is that all the bindings and such that Ember.View has created stay in memory, so we have to either have the developer manually manage memory, or do some fanciness in Tower, which could get complex. I tried going down that road once but it seemed it would take a lot of time and not produce that much fruit. The cost of manually "disabling" Ember bindings and such on "non-visible" (cached) views quickly becomes just as expensive as just destroying and re-creating the view.
The one situation where it would be useful is if the view doesn't contain much dynamic data (such as a page-specific menu that might get added/removed when the URL changes, but doesn't change it's content). In that situation it may be beneficial to cache the views.
Overall, I agree with you that we should refactor the Tower.NetConnection interface so that it's a cleaner interface to all things user. Seems like you have a solid idea of what should happen and it only really comes down to the specific API. Let me know what you're thinking next, this is definitely a powerful component that will be very useful when simplified.
thehydroimpulse
edubkendo
Right now the
Tower.Netand the whole networking infrastructure seems a little weird... It would be awesome to be able to have aTower.NetManagerthat would be available withinTower.Application.instance().My idea is to have an array of connections within this class instance that would hold all the information about the user:
This would allow a really good centralization unit for instances, sockets, ajax, etc...
Tower.NetManagerwould present a good DSL to retrieve and use the information provided. It would also be much simpler to access the information as it's extremely centralized.Again the DSL would need to be thought out a lot more. But this would allow to retrieve this information from anywhere and would allow building on this extremely easy. You could also provide interfaces to send or emit socket / ajax messages to specific clients (with a restriction system), all clients, etc... Maybe a DSL close to what models have but with less options obviously.
Because at the moment, the current way of manipulating sockets, clients and class instances is a little hacky / clunky.
Thought?
(Maybe i'm going in the wrong direction here and something like this already exists? I just started on actually implementing this... so well see.)