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

[Steve Swinsburg]

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"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20131116/03a7a4a6/attachment.html