[sakai2-tcc] Roster2 to replace Roster

Mon Sep 16 14:48:09 PDT 2013

Yea there's a hashtable and ehcache on the ResourceLoader, so it's just one
extra call you that. You can just take as a given that you don't need to
cache on the rest layer.

On Mon, Sep 16, 2013 at 5:38 PM, Adrian Fish <adrian.r.fish at gmail.com>wrote:

> CLOG will benefit from the same approach as well. I can do the REST target
> in kernel if nobody else has time at present. I presume just a JSON feed of
> all the pairs for a particular sakai tool id, localised to the current
> user, will do the job? What about caching though? I presume that'll be
> abstracted away behind the resource loader call?
>
> Cheers,
> Adrian.
>
>
> On 16 September 2013 22:34, Adrian Fish <adrian.r.fish at gmail.com> wrote:
>
>> ... and I this one:
>>
>> https://jira.sakaiproject.org/browse/RSTR-62
>>
>>
>> On 16 September 2013 16:59, John Bush <jbush at anisakai.com> wrote:
>>
>>> I created this one:
>>>
>>> https://jira.sakaiproject.org/browse/KNL-1122
>>>
>>>
>>> On Mon, Sep 16, 2013 at 6:58 AM, Aaron Zeckoski <azeckoski at unicon.net>
>>> wrote:
>>> > It's more that the i18n data would load from the ResourceLoader (which
>>> > mostly means loading from the properties files in that vast majority
>>> > of cases and not from the database).
>>> > -AZ
>>> >
>>> > On Mon, Sep 16, 2013 at 9:49 AM, Adrian Fish <adrian.r.fish at gmail.com>
>>> wrote:
>>> >> If I read things correctly, yes. Roster2 will replace Roster in trunk
>>> if and
>>> >> when the i18n packs are loaded from the db. That will mean 2.10,
>>> think.
>>> >>
>>> >> Cheers,
>>> >> Adrian.
>>> >>
>>> >>
>>> >> On 16 September 2013 12:08, Neal Caidin <neal.caidin at apereo.org>
>>> wrote:
>>> >>>
>>> >>> Does this mean that some changes will be made to Roster2 and it will
>>> be
>>> >>> targeted for 2.10/Trunk?
>>> >>>
>>> >>> Thanks,
>>> >>> Neal
>>> >>>
>>> >>>
>>> >>>
>>> >>> Neal Caidin
>>> >>> Sakai CLE Community Coordinator
>>> >>> neal.caidin at apereo.org
>>> >>> Skype: nealkdin
>>> >>> Twitter: ncaidin
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Sep 16, 2013, at 4:40 AM, Adrian Fish <adrian.r.fish at gmail.com>
>>> wrote:
>>> >>>
>>> >>> Alright, already ... :)
>>> >>>
>>> >>> If it's not JIRA'd, could one of you fine fellows raise a ticket? I
>>> like
>>> >>> Matthew's generic REST target idea; it does sound like people have
>>> done this
>>> >>> a couple of ways, so standardising going forward makes sense.
>>> >>>
>>> >>> Cheers,
>>> >>> Adrian.
>>> >>>
>>> >>>
>>> >>> On 13 September 2013 15:35, John Bush <jbush at anisakai.com> wrote:
>>> >>>>
>>> >>>> Right that is the other benefit, anyone who just talks in English
>>> and
>>> >>>> wants to change the instructional text on the site editor page...
>>> >>>> Problem solved.  Without that you end with forked nightmares, been
>>> >>>> there done that.
>>> >>>>
>>> >>>> On Fri, Sep 13, 2013 at 7:30 AM, Matthew Jones <
>>> matthew at longsight.com>
>>> >>>> wrote:
>>> >>>> > We are making heavy use of the dynamic translations. If you're
>>> just one
>>> >>>> > school, maybe it's not a huge time saver but it is for managing
>>> dozens.
>>> >>>> > Still the flexibility it gives for a single school (being able to
>>> put
>>> >>>> > up a
>>> >>>> > clarifications, warnings or new information immediately) is pretty
>>> >>>> > great. It
>>> >>>> > saves on a lot of code changes, keeping custom forks up dated and
>>> >>>> > providing
>>> >>>> > much quicker fixes. Even though there was a bug where it was
>>> going to
>>> >>>> > the DB
>>> >>>> > a lot more than expected (soon to be fixed in 2.9.x SAK-23887),
>>> it was
>>> >>>> > still
>>> >>>> > worth it to save on the code changes/redeploys. So i'd say having
>>> this
>>> >>>> > feature consistent for everything is a good thing.
>>> >>>> >
>>> >>>> >
>>> >>>> > On Fri, Sep 13, 2013 at 10:24 AM, Adrian Fish <
>>> adrian.r.fish at gmail.com>
>>> >>>> > wrote:
>>> >>>> >>
>>> >>>> >> There's also jquery's way:
>>> >>>> >>
>>> >>>> >> https://code.google.com/p/jquery-i18n-properties
>>> >>>> >>
>>> >>>> >> It uses standard java property files so translations can handled
>>> with
>>> >>>> >> the
>>> >>>> >> same tools. It doesn't solve the dynamic updating of i18n props
>>> >>>> >> though. How
>>> >>>> >> important is that though? How often do people actually need to
>>> >>>> >> dynamically
>>> >>>> >> update translations, and is it worth the overhead of hitting the
>>> db or
>>> >>>> >> cache
>>> >>>> >> to get them?
>>> >>>> >>
>>> >>>> >> Cheers,
>>> >>>> >> Adrian.
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> On 13 September 2013 15:10, John Bush <jbush at anisakai.com>
>>> wrote:
>>> >>>> >>>
>>> >>>> >>> There's at least one thing I'd like to see addressed.
>>> >>>> >>>
>>> >>>> >>>
>>> >>>> >>>
>>> >>>> >>>
>>> https://source.sakaiproject.org/contrib/roster2/trunk/roster-app/src/webapp/roster-translations-ca.js
>>> >>>> >>>
>>> >>>> >>> I don't find that an acceptable way of doing localization.  Its
>>> not
>>> >>>> >>> consistent with the rest of Sakai, and it won't work with the
>>> dynamic
>>> >>>> >>> manipulation of bundles.  It makes it harder for anyone who is
>>> used
>>> >>>> >>> to
>>> >>>> >>> working with properties to maintain this stuff, since tools
>>> won't
>>> >>>> >>> support this arbitrary js format.
>>> >>>> >>>
>>> >>>> >>> It easy to address, I had to do it for gb2.  You need to just
>>> create
>>> >>>> >>> a
>>> >>>> >>> servlet that loads this the data from the ResourceLoader and
>>> then
>>> >>>> >>> transforms it into your javascript format.
>>> >>>> >>>
>>> >>>> >>> Also, I'd like verification that there aren't any FERPA issues
>>> >>>> >>> introduced.   I see
>>> https://jira.sakaiproject.org/browse/RSTR-16, but
>>> >>>> >>> its worth asking just to be sure.
>>> >>>> >>>
>>> >>>> >>> On Fri, Sep 13, 2013 at 6:54 AM, Steve Swinsburg
>>> >>>> >>> <steve.swinsburg at gmail.com> wrote:
>>> >>>> >>> > I proposed it years ago. Better integration, better support,
>>> more
>>> >>>> >>> > features, same UI as old roster tool.
>>> >>>> >>> >
>>> >>>> >>> > Cheers,
>>> >>>> >>> > S
>>> >>>> >>> >
>>> >>>> >>> > Sent from my iPad
>>> >>>> >>> >
>>> >>>> >>> > On 13/09/2013, at 23:45, Aaron Zeckoski <azeckoski at unicon.net
>>> >
>>> >>>> >>> > wrote:
>>> >>>> >>> >
>>> >>>> >>> >> Those notes were from the conference back in June and have
>>> just
>>> >>>> >>> >> been
>>> >>>> >>> >> slightly reorganized. I am not sure who proposed replacing
>>> roster
>>> >>>> >>> >> with
>>> >>>> >>> >> roster 2 but maybe that person can add the reasoning. I am
>>> not
>>> >>>> >>> >> aware
>>> >>>> >>> >> of anything myself.
>>> >>>> >>> >>
>>> >>>> >>> >> On Fri, Sep 13, 2013 at 9:31 AM, May, Megan Marie <
>>> mmmay at iu.edu>
>>> >>>> >>> >> wrote:
>>> >>>> >>> >>> I don’t see rationale in the notes.   Can you please provide
>>> >>>> >>> >>> something
>>> >>>> >>> >>> substantial for those of us not on the call?
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> From: sakai2-tcc-bounces at collab.sakaiproject.org
>>> >>>> >>> >>> [mailto:sakai2-tcc-bounces at collab.sakaiproject.org] On
>>> Behalf Of
>>> >>>> >>> >>> Neal
>>> >>>> >>> >>> Caidin
>>> >>>> >>> >>> Sent: Friday, September 13, 2013 7:37 AM
>>> >>>> >>> >>> To: sakai2-tcc at collab.sakaiproject.org 2
>>> >>>> >>> >>> Subject: [sakai2-tcc] Roster2 to replace Roster
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> From the TCC - CLECC call -
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> https://confluence.sakaiproject.org/display/TCC/TCC+CLE+Action+Items
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> For the folks on the call, there was consensus that Roster2
>>> >>>> >>> >>> should
>>> >>>> >>> >>> replace
>>> >>>> >>> >>> Roster for 2.10/trunk.
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> Steve Swinsburg says this is not a lot of work to make
>>> happen.
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> Consensus on this one?
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> Cheers,
>>> >>>> >>> >>>
>>> >>>> >>> >>> Neal
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> Neal Caidin
>>> >>>> >>> >>>
>>> >>>> >>> >>> Sakai CLE Community Coordinator
>>> >>>> >>> >>>
>>> >>>> >>> >>> neal.caidin at apereo.org
>>> >>>> >>> >>>
>>> >>>> >>> >>> Skype: nealkdin
>>> >>>> >>> >>>
>>> >>>> >>> >>> Twitter: ncaidin
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>>
>>> >>>> >>> >>> _______________________________________________
>>> >>>> >>> >>> sakai2-tcc mailing list
>>> >>>> >>> >>> sakai2-tcc at collab.sakaiproject.org
>>> >>>> >>> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>>> >>> >>
>>> >>>> >>> >>
>>> >>>> >>> >>
>>> >>>> >>> >> --
>>> >>>> >>> >> Aaron Zeckoski - Software Architect -
>>> http://tinyurl.com/azprofile
>>> >>>> >>> >> _______________________________________________
>>> >>>> >>> >> sakai2-tcc mailing list
>>> >>>> >>> >> sakai2-tcc at collab.sakaiproject.org
>>> >>>> >>> >> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>>> >>> > _______________________________________________
>>> >>>> >>> > sakai2-tcc mailing list
>>> >>>> >>> > sakai2-tcc at collab.sakaiproject.org
>>> >>>> >>> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>>> >>>
>>> >>>> >>>
>>> >>>> >>>
>>> >>>> >>> --
>>> >>>> >>> John Bush
>>> >>>> >>> 602-490-0470
>>> >>>> >>>
>>> >>>> >>> ** This message is neither private nor confidential in fact the
>>> US
>>> >>>> >>> government is storing it in a warehouse located in Utah for
>>> future
>>> >>>> >>> data mining use cases should they arise. **
>>> >>>> >>> _______________________________________________
>>> >>>> >>> sakai2-tcc mailing list
>>> >>>> >>> sakai2-tcc at collab.sakaiproject.org
>>> >>>> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>>> >>
>>> >>>> >>
>>> >>>> >>
>>> >>>> >> _______________________________________________
>>> >>>> >> sakai2-tcc mailing list
>>> >>>> >> sakai2-tcc at collab.sakaiproject.org
>>> >>>> >> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>>> >>
>>> >>>> >
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> John Bush
>>> >>>> 602-490-0470
>>> >>>>
>>> >>>> ** This message is neither private nor confidential in fact the US
>>> >>>> government is storing it in a warehouse located in Utah for future
>>> >>>> data mining use cases should they arise. **
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> sakai2-tcc mailing list
>>> >>> sakai2-tcc at collab.sakaiproject.org
>>> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> sakai2-tcc mailing list
>>> >> sakai2-tcc at collab.sakaiproject.org
>>> >> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>> > _______________________________________________
>>> > sakai2-tcc mailing list
>>> > sakai2-tcc at collab.sakaiproject.org
>>> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>>
>>>
>>>
>>> --
>>> John Bush
>>> 602-490-0470
>>>
>>> ** This message is neither private nor confidential in fact the US
>>> government is storing it in a warehouse located in Utah for future
>>> data mining use cases should they arise. **
>>>
>>
>>
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130916/67219ef5/attachment-0001.html 