Show list of logged in Users

[mrculler]

The source material actually shows all user accounts on the system. Sounds like this issue is more about parsing the output of the w command. I'm not really sure what kind of system we're targeting here - for my home server neither really matters.

[davidfic]

I agreee. I want to look into making a more flexible front page. Maybe use jQuery containers that we can selectively add, remove and re-arrange. That way the front page can be tailored to different use cases.

As an example check out this link: http://nettuts.s3.amazonaws.com/127_iNETTUTS/demo/index.html

I don't think that would be too difficult.

We can also think about using the Flask-Admin extension to allow the user to customize the output even more.

[mrculler]

I like the jQuery containers idea.

To me, everything seems to be driving towards handling all the "stats" (or whatever you'd call each thing put into a box on the webpage) generically. Simple classes implementing an interface on the backend (never done OO python, so I'm making some assumptions here) and a separate template for each one. Once we get to updating the UI automatically, we'll probably want to update some frequently and others not as frequently, so we can define an update interval for each stat and then generate a combined XHR request for new data. If stat "a" is updated every 5 seconds and "b" is updated every 10, then 5 seconds after loading, the page would send a request to the server along the lines of get=[a] and the server would return a JSON object like {a: [...]}, then after 10 seconds the page would send get=[a,b], and the server would respond with {a:[...], b: [...]}.

Makes sense? Does this sound right?

[apiguy]

The user interface paradigm you folks are discussing is most commonly known as widgets, wherein a view that the user sees is composed of several separate widgets each containing their own data and functionality.

jQuery isn't going to give you this capability out of the box, however it's a common enough pattern that you shouldn't have much trouble getting something working.

As far as getting the widget data updated, having each one independently make callbacks to the server to get started should be fine, each widget managing it's own timer, and making a call to the server to get data. Eventually though you'll need to create a central request dispatch on the client so that you don't overwhelm your server with more requests than are really needed.

For example - if you had 10 widgets on the view and each one had a 5 second refresh, you'd be making 10 requests to the server every 5 seconds just for keeping the page open. If several people have this page open it simply multiplies. Instead you might consider using a central request dispatcher which each widget can register itself with and send requests to. The central request dispatcher can bundle several requests together and then split the results appropriately for each widget. This way you can turn 10 requests every 5 seconds into 1 or 2.

I'd build it without the central request dispatch at first however, as refactoring to it once you have a set of functional widgets shouldn't be too complicated.