Did you miss another post in this short thread? 
yeah, me too. I have a survey to the community. The changes belowe would be quite fundamental, so they should be implemented (or not!) before 1.0.
1. Shall we make Drab JS static?
Now, Drab javascripts are eex templates, so they are generated each time depending on config, action, controller, etc etc. The benefit is that we can shrink the whole stuff when not using some of Drab Modules.
But, if we make JSes static, they could be cacheable and shrinkable.
2. Shall we pass the token via cookie? (and have Drab.Plug)
You can see this discussion few pages above. The whole idea is to create a plug which creates a cookie with token, instead of passing it in the page source with Drab.Client.run in app.html.eex
3. Shall we enable Drab on all pages in the application?
If we do 1. and 2., Drab.Client.run in app.html.eex will be obsolete, as Drab will run on each page. Now, Drab.Client.js checks, for example, if the commander exists, and if not, does not inject JS and does not run Drab client.
By the other hand, I think it is not impossible to check the existence of the commander (and other checks) in the plug, so we could keep at least part of the functionality (Drab JS will be loaded, as it is static, but not try to connect).
4. Shall we create own structure and use it instead of %Phoenix.Socket{}?
Drab now base on the socket structure, so socket is passed to every handler function, and all drab functions rely on the socket. But the “Drab socket” contains more information than the ordinary one. So far we store it in assigns field as underscore__underscore fields, eg. __drab_pid. This works, but is not very elegant obviously.
I’ve tried to use private field in the socket struct, which requires a small change in Phoenix, but @chrismccord suggested to make the own structure. Obviously this struct will store a socket as well, something like:
%Drab.Drut{socket: Phoenix.Socket.t(), pid: pid, controller: atom, action: atom, store: map, session: map, ...}
I don’t know what to think about it, it’s elegant, but I still like the idea of two worlds, render-time (conn and controller) and run-time (socket and commander).
5. Shall we have a full read/write access to the Plug Session?
It can be done, if we have a plug (might be the same from point 2.) which is called before :fetch_session, as it destroys the session cookie name and access method. It is risky, as Drab handlers may be run in parallel. One function may overwrite the session and you’re not aware of it.
6. Shall Drab support user_ids, disconnections?
Very recent discussion. Now Drab does not care about which user is connected. Shall we create a support for users? And the most important question, how? I would be grateful for any API propositions
