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

[Steve Swinsburg]

Ok, extended until Thursday December 5th.


On Thu, Nov 28, 2013 at 1:29 AM, Aaron Zeckoski <azeckoski at unicon.net>wrote:

> I agree with this but I think the timing here is problematic. Most
> people in the US will not even see this note until after the
> expiration date because of the thanksgiving holiday. My objection
> therefore is on the date.
>
> Extend it to Thursday Dec 5th instead so there are a few days for
> people to review it. I doubt anyone will disagree but we should
> generally provide enough time for feedback.
>
> -AZ
>
>
> On Wed, Nov 27, 2013 at 6:56 AM, 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
> >
> >
> > _______________________________________________
> > cle-release-team mailing list
> > cle-release-team at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> >
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20131128/1dbef842/attachment.html