Add paging capability to entity providers

I see what you mean, auth decisions need to be taken on an individual basis for each image, so a sprite would be out. It would be nice though, just one HTTP request ...

Regarding caching, even if the images are cached, we're still talking about a big hit initially.

Throwing out the sprite idea, how about discussing the actual use case we're trying to address? In a 5K user site, what would a student or tutor want to browse the roster for? Might they want to look for a particular user? If so it might make sense to have paging and searching as searching will avoid a lot of http requests.

Combining a bunch of user profile images into a sprite wouldn't really be possible and sounds unnecessary. Firstly, there are too many changes that a user could do on the profile side that would trigger the sprite redrawing process, which would be very CPU intensive for a large site. Second, changes in the way the profile image works in relation to individual users could be limited since you would have to assume that every user in a site can see the exact same image of another user which would go against the profile2 privacy/prefs system.

If there was paging on the client side then the image would only be rendered as each page of members was displayed. I don't see how this is any different than going to Google images and rendering a page of 20 or more images. The URL to a profile image is fixed for a user and the browser will cache it.

If need be we could look at more caching on the Profile2 side specifically for profile images, I'm just concerned about blowing out memory usage if thousands of users upload large profile images which is why that hasn't been implement yet. Objects take up little space, binary takes up lots.

Mark, is it render time on the browser that doesn't scale, or server response? If it is server response, then obviously client side paging won't really help. I foresee the biggest hit being the rendering of all the user profile pictures. Each one is a separate http request, so it may be good to investigate actually combining the user images into a single sprite and somehow load this in the background. Roster 2 would have to do this; it could be precomputed on Sakai events like a user being added to a site, or an update picture event from Profile2.

On the other hand, do we even need to render all the users in a 5000 member worksite? Would we actually want to browse that, rather than just search for a particular user? I think that's a reasonable question.

I fully support this. Without paging most tools in Sakai don't scale very well beyond 500 users in a worksite or so.

IIRC, EntityBroker already does paging, however for simplicity I'd probably just implement this in the UI. Have one fetch for the data and have client side paging. It would then mean only one request is made to the server, and would keep things synchronised too, i.e. if the list of participants changed whist you were paging. WDYT?