[Building Sakai] [cle-release-team] Proposal: Replace Roster with Roster 2, fully retire Profile 1

Thu Nov 21 18:48:41 PST 2013

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.

cheers,
Steve

p.s. cross posted to ticket.

On Thu, Nov 21, 2013 at 8:31 PM, Adrian Fish <adrian.r.fish at gmail.com>wrote:

> This is a comment I posted on RSTR-67, about scalability of roster2. I'd
> like a few people's take on this, if possible. If anybody has advice,
> please post it on the ticket.
>
> "Mark (Breuker), 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."
>
> Cheers,
> Adrian.
>
>
> On 18 November 2013 10:54, JUAN JOSé MEROñO SáNCHEZ <jjmerono at um.es>wrote:
>
>>
>> Done !!
>> https://jira.sakaiproject.org/browse/RSTR-67
>>
>> Thanks !!
>>
>> El 18/11/2013 11:20, Adrian Fish escribió:
>>
>> Hi Juan,
>>
>>  Go ahead and JIRA it, yes. We can discuss further on the ticket.
>>
>>  Moocs, eh? Woooo. I mean, Moooo.
>>
>>  Cheers,
>> Adrian.
>>
>>
>> On 15 November 2013 20:13, Steve Swinsburg <steve.swinsburg at gmail.com>wrote:
>>
>>> Good suggestion, can you file that in the RSTR project in Jira? I would
>>> suggest it be done client side to make things faster and make just one
>>> request to the server (i.e. list is fetched, paging occurs client side) but
>>> we would need to do some performance analysis. This would keep things
>>> synchronised too, i.e. if the list of participants changed whist you were
>>> paging.
>>>
>>>  cheers,
>>> Steve
>>>
>>>
>>>  On Fri, Nov 15, 2013 at 9:39 PM, JUAN JOSé MEROñO SáNCHEZ <
>>> jjmerono at um.es> wrote:
>>>
>>>>   I've got one suggestion for roster2.
>>>>
>>>> In terms of performance it would be nice if all the lists presented in
>>>> roster2 were paginated (participants, photos,...).
>>>> I'm talking about the posibility of adding paging capability to
>>>> Roster2's EntityProviders, similar as it was done with SiteEntityProvider
>>>> in SAK-20661.
>>>> I'm sure that all mooc efforts will appreciate this feature in roster2,
>>>> and also it will provide another reason to replace roster.
>>>>
>>>> Thanks !!
>>>>
>>>> El 15/11/2013 3:38, Steve Swinsburg escribió:
>>>>
>>>>  *Proposal*
>>>>
>>>>  1. Remove Roster 1.
>>>>
>>>>  2. Add Roster 2.
>>>>
>>>>  3. Fully remove Profile 1. The tool has been deprecated and removed
>>>> for some time, the API is the only part remaining.
>>>>
>>>>
>>>> *Rationale *
>>>>
>>>>  Roster 1 has been without proper community support for some time.
>>>> When Profile2 was developed (2008, released 2009), both Profile2 and
>>>> Profile1 ran side by side. The Profile1 tool was eventually deprecated and
>>>> removed from the release in 2.8. However, due to architectural
>>>> requirements, the Profile2-Roster1 integration depended on the Profile1 API
>>>> and this is still deployed in the release.
>>>>
>>>>  Roster2 was subsequently developed (2010) with the same UI and base
>>>> feature set as Roster1, but in a newer UI technology and more
>>>> functionality. The Roster2-Profile2 integration uses EntityBroker and thus
>>>> there is no direct API dependency between the two.
>>>>
>>>>  Due to the evolution of Profile2 and the number of image, privacy and
>>>> preference combinations available, the Profile2-Roster 1 doesn't work
>>>> fully, and no more work will be spent in this area.
>>>>
>>>>  The Roster2-Profile2 link is a complete integration and respects all
>>>> privacy and preference configurations. With this tool in place, the
>>>> Profile1 API can be fully retired.
>>>>
>>>>  Roster2 is a contrib tool, currently in use at a number of sites
>>>> including Lancaster University and New York University [1].
>>>>
>>>>  Roster2 is currently deployed on the nightly+experimental server [2].
>>>>
>>>>   Roster2 is currently maintained by Adrian Fish and Steve Swinsburg.
>>>>
>>>>  *Where to from here*
>>>>
>>>>  Read the rationale above. A material objection (indicated by a -1 and
>>>> accompany reasoning) raised by a Sakai PMC member will block this proposal.
>>>>  Other opinions are welcome, indeed encouraged. Silence equals consent.
>>>>  Discussion should be on the sakai-dev list unless of a private nature
>>>> in which case I am happy to correspond off list. Objections must be
>>>> received before Friday 22nd November 2013 (two weeks from now).
>>>>
>>>>  *Links*
>>>>
>>>>  1. https://confluence.sakaiproject.org/display/RSTR/Roster2
>>>> 2. http://nightly2.sakaiproject.org:8085/portal
>>>>
>>>>
>>>>
>>>>  _______________________________________________
>>>> cle-release-team mailing listcle-release-team at collab.sakaiproject.orghttp://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>>>>
>>>>
>>>>
>>>>  _______________________________________________
>>>> sakai-dev mailing list
>>>> sakai-dev at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email to
>>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>>> "unsubscribe"
>>>>
>>>
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to
>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>> "unsubscribe"
>>>
>>
>>
>>
>> _______________________________________________
>> sakai-dev mailing listsakai-dev at collab.sakaiproject.orghttp://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20131122/5b5a1e35/attachment.html 