Thomas Vandahl wrote:
Scott Eade wrote:
Candidates for deprecation in 2.3.3:
* ScheduleService - not going to be ported to Fulcrum, use Fulcrum
Quartz instead
* LocalizationService - use Fulcrum Localization instead - relevant
classes have not been carried over to trunk/2.4 so it should have
been deprecated already anyway
* IntakeService - same situation as l10n service
* MimeTypeService - ditto
* A bunch of other services for which we have Fulcrum components do
still actually exist in the trunk/2.4 - should we not deprecate
these also now so that we can have a cleaner base to work on with 2.4?
I'd not deprecate any services in the 2.3 branch, I expressed my
concerns about the state of their Fulcrum counterparts already. At least
their inter-dependencies need to be resolved. Localization and Intake
rely on the Factory and Pool services and the Parser component, which in
turn depends on the Upload service. If you want to use one of them, you
need to replace all. I would not want to recommend this to the user as
long as we haven't sorted that mess out.
Nothing says that we have to remove something that is deprecated in the
immediately following release, but then it is also not really good form
to deprecate things before the replacements are available.
Using this criteria I would suggest that we proceed with deprecating the
ScheduleService since it is pretty much stand alone and it has a
reasonably serious issue relating to DST that is unlikely to be addressed.
For the other services, I agree with your reasoning - i.e. let's hold
off until their replacements have been fully implemented in the desired
fashion.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
