5:08 a.m.
Hey Mazz,
[ While this was not asked, we should nevertheless keep it in mind for
the future: those request / response pairs (of 'important' things)
should be audit logged and also be available in some form of message
viewer in case that the user wants to check stuff and/or it not logged
in at time of completion ]
1) I'm logged into the UI using two different browser tabs. In
one, I
send a "deploy an application" request. Once the response comes back -
do I show the response in both tabs? What if I closed the tab that
performed the deploy? What should happen?
Show in both.
2) I am logged in kettle #1 as "jdoe" and someone else is
logged in
kettle #2 as the same "jdoe". I deploy an application. Should that
other person get the response that a new app was deployed, too?
Yes. I guess that in this case it is even more important.
3) I am logged into the UI and I deploy an application. I log out
(perhaps close the browser) and log back in. Then the deployment
finishes and the response comes in - should I get that response (even
though its a new browser instance and a new websocket connection?)
If you are logged in: yes. Otherwise see above.
The questions start to become more interesting when
multiple users of an organization (tenant) are logged in.
How much do we want to show here?
Spamming all org users with every message is certainly wrong.
Allowing others to look them up (-> audit) may be a good idea
(depending on permissions).
Another thing I am thinking is have it work just like feeds - a feed
connects via the URL ws://host/hawkular-command-gateway/feed/<FEED
ID>. We could let each UI generate their own id and connect via
ws://host/hawkular-command-gateway/ui/<UI ID>. The good thing here is
the UI knows its ID immediately (since it generated it) and we know it
from the start without even getting an initial message (and we can
link it with that websocket session easily). Bad thing is only that UI
will be able to get responses - it won't work the "Google Drive way"
where a user logged into N browsers will get responses in all N
browsers.
Isn't a UI always tied to a user? In that case when the UI
"logs into the server", the server(s) can keep a list of
user->ui(s) mappings. I think it is very valid to open a/the
websocket on initial login into the UI and then just
use that all over the place where it is needed until the
user logs out or closes the browser.