[sakai-core-team] Couple or large changes to caching and eventing merging back to Sakai 10

[Aaron Zeckoski]

There are no changes to event handling or caching or sessions
management. These tickets all just make it possible for Sakai to
actually support distributed caching, distributed events, and session
replication. All of that functionality is disabled by default (or
simply not enabled) but the API changes were necessary to make it
possible. It is similar to when I added support to the kernel for
configuration providers in 2.9 but there were no configuration
providers implemented yet or when I added support for antisamy but it
was disabled.

Adding support often will require changes to APIs and those changes
are important to get in before a release.

In short, no new functionality is enabled, all existing tests are
passing, this has all been discussed.

Let's please avoid further misinformation and confusion.

I welcome anyone who wants to contribute to the effort and review the
code and help test. Other activity is not helpful and distracts from
the 10 release.

-AZ


On Tue, Apr 15, 2014 at 9:28 AM, David Haines <dlhaines at umich.edu> wrote:
> My understanding from the core call on 4/10/14 was the the memory changes
> were to be adding api calls compatible with JSR-107 and removal of unused
> code.  There would also be a small change to deal with the fact that some
> ehcache event calls were done directly.  In essence the 2.9 implementation
> would remain but the api to allow using a different JSR-107 implementation
> would be introduced.
>
> Changes to event handling were not discussed and I assume are not part of
> the last minute changes.
>
> If the scope of the changes is different than the above or it doesn't seem
> that this work will be done and verified in Sakai 10 by 4/18/14 I think
> further discussion is appropriate.
>
> - Dave
>
>
> On Tue, Apr 15, 2014 at 5:01 AM, Matthew Buckett
> <matthew.buckett at it.ox.ac.uk> wrote:
>>
>> There's recently been some good work on making Sakai work with
>> standard JSR-107 caches [1] and allowing events to be propagated
>> through a mechanism other than the database [2]. Both of these
>> features make Sakai easier to deploy in large setups and should make
>> better use of existing resources.
>>
>> However I'm just a little concerned that merging these back into the
>> Sakai 10 branch while we are trying to cut a release risks holding up
>> the release. I was under the impression that features for Sakai 10
>> should have gone in by January 15 [3].
>>
>> I'm raising this partly because locally we are looking to run Sakai 10
>> early and have been working on reviewed how local changes interact
>> with what we believed to be the features in the Sakai 10 branch.
>>
>> Aaron has said that this was all discussed before the cutoff[4] but
>> not having been able to attend ApereoCamp I don't know what was said.
>>
>> [1] https://jira.sakaiproject.org/browse/KNL-1162
>> [2] https://jira.sakaiproject.org/browse/KNL-1184
>> [3]
>> https://confluence.sakaiproject.org/display/PMC/Proposal%3A+Sakai+10+release+schedule
>> [4]
>> https://jira.sakaiproject.org/browse/KNL-1162?focusedCommentId=190160&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-190160
>>
>> --
>>   Matthew Buckett, VLE Developer, IT Services, University of Oxford
>> _______________________________________________
>> sakai-core-team mailing list
>> sakai-core-team at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>
>
>
> _______________________________________________
> sakai-core-team mailing list
> sakai-core-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>



-- 
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile