Hi Eric,
+) Regarding Releases
===================================================
Don't get me wrong - I was just stating the obvious.
What I suggest is to cut a Turbine 2.4 M2 release to get rid of the
currently deprecated Turbine services and to deprecate the services you
mentioned below. But sooner or later a release is needed since the last
Turbine milestone release is 12 months old.
+) Lending a hand
===================================================
I'm not of great help cleaning up Turbine code since I'm currently not
using the full-fledged Turbine stuff just a few services. Actually my
only Turbine application should be completely migrated to Avalon
services ... ;-)
What I can do is to rework the Turbine service framework to allow
transperant service lookup and the XMLRPC service is on my list anyway.
Furthermore providing some XDOCs to existing services ...
Cheers,
Siegfried Goeschl
Eric Pugh wrote:
I hear you on the deprecation stuff, and normally I would agree.. But
I think that Turbine 2.5 is at least a year away, and the sheer volume
of deprecated content is daunting. If you look at it, these services
are all deprecated:
* cache
* crypto
* factory
* localization
* mimetype
* pool
Not deprecated, but will be soon:
* intake
* pull
* xmlrpc
Not deprecated at all
* assemblerbroker
* naming
* schedule (should this be deprecated in favor of Quartz?)
* security (but maybe should be?)
Additionally, there is a TON of other non service related code that has
been deprecated in previous releases that will go. So, I don't want to
be dogmatic about "deprecated code exists for one release" because I
actually think that will actually not be in our users favor. Users who
have dependencies in 2.3 on deprecated code will need to fix those to
go to 2.4, so, if they are going to be doing updates, I say get those
over with, and force them to move to the Avalon file configuration as
well. Versus making a set of fixes for 2.3 -> 2.4, and then a second
set of fixes for 2.4 -> 2.5.
I'm also concerned about the maintenance of code. Currently every time
a bugfix is applied in the T2.3 branch, one of the committers has to
catch it and apply it to the 2.4 trunk AND the corresponding Fulcrum
codebase. This has led to bug fixes being lost in the past. And,
getting new developers in is confusing, because of all the duplication.
I want 2.4 to be a good foundation for the future, and I think that
keeping the old Turbine code doesn't help that.
I would also be interested in feedback (and help!) on converting the
remaining services to Fulcrum/Avalon.
Eric Pugh
On Oct 27, 2005, at 11:32 AM, Siegfried Goeschl wrote:
Hi Eric,
I'm just stating the obvious ...
1) deprecated stuff should stay around for at least one release - no
matter how little time is between two releases ... :-)
2) were there any commits regarding the deprecated Turbine services
not being reflected in the Fulcrum services?
Cheers,
Siegfried Goeschl
Eric Pugh wrote:
Hi all,
In an attempt to chip away at the circular dependency between T2.4
and Fulcrum Intake, I took the plunge of change T2.4 to use the
Fulcrum Factory and Pool services. I am ready to commit that
patch. I've attached a diff for review.
However, as I have gone through fixing everything, I have found
that MOST of the Turbine codebase is deprecated in favor of the
Fulcrum equivalents. Is there any really good reason to keep them
in the codebase, as the migration to Fulcrum is supposed to REMOVE
those things, not duplicate every service twice!
I'd like to remove the deprecated code in a seperate commit.
Comments?
Eric
---------------------------------------------------------------------
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
