[cle-release-team] Proposal: Retiring the old ArchiveServiceImpl

[Steve Swinsburg]

Hi all,

The deadline for comments is extended until Wednesday 4th December due to the next couple of days being holidays in the US.

cheers,
Steve


On 27 Nov 2013, at 10:56 pm, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:

> Hi all,
> 
> As some of you may be aware, there currently exists two implementations of the ArchiveService API within the common/archive-impl module. The first (BasicArchiveService) was disabled some time ago and remains for historical purposes. The second (ArchiveService2Impl) is the one that is turned on by default and features a pluggable architecture as well as better configuration.
> 
> From the README in common:
> 
> "ArchiveService2Impl allows you to customize which entities are imported during the merge process. Previously, the list of allowable services was Hardcoded in the Service itself. All other behaviour, as well as the API, are the same."
> 
> The new code is identical to the old code but is laid out better, plus as mentioned, it is configurable via Spring rather than hardcoded within the class itself. This means that newer tools like Lessons have been abled to leverage the archive capabilities of the new implementation, but are unsupported in the old implementation without a code change.
> 
> I have been working in this area a lot recently adding some new features and have extended the ArchiveService API. This means I needed to stub out some methods that do nothing in the old ArchiveService implementation to get things to compile (since it directly implements that interface). This makes code maintenance more difficult and is unnecessary when the code isn’t even in use. I cannot see a reason for anyone to switch on this old implementation when the new implementation is logically identical to the old.
> 
> To reduce all of this overhead and redundant code, I therefore propose that the old archive service implementation be removed from trunk. 
> 
> 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 Sunday 1st December 2013 (five days from now).
> 
> regards,
> Steve
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20131127/710011cd/attachment.html