[ipn-devel] FW: Turbine 2.x vs Turbine 3.0

[Everson D. <DAE...@AG...>]

FYI.  Here is the response that I got from one of the major Turbine
developers.  I think that we should implement some of his suggestions when
we develop IPN so that the transition to Turbine 3.0 at some point in the
future is more smoother.  

Last weekend, I read up on the pull services.  I dismissed it at the time
because it was not well documented and seemed complex.  I plan on re-reading
this material once again. 

Dave

-----Original Message-----
From: Jason van Zyl
To: tur...@ja...
Sent: 9/14/01 3:16 PM
Subject: Re: Turbine 2.x vs Turbine 3.0

On 9/14/01 3:44 PM, "Everson Dave" <DAE...@AG...> wrote:
 
> Since I am new to the whole Turbine framework, I am wondering exactly
how
> different is Turbine 3.0 from Turbine 2.x.  Will much of what we
implement
> with Turbine 2.x have to be rewritten or modified in 3.0?  Is there a
list
> of functionality that is being modified or removed in 3.0?

Internally Turbine 3.0 will be very different than Turbine 2.0. Turbine
3.0
will not be a drop in replacement but the TDK is evolving to include
migration tools which should make the process relatively painless. As
more
people migrate applications and run into problems the migration process
will
become more complete.

The use of pull tools will definitely help your migration. If you can
avoid
creating individual modules than you will be far better off. I believe
that
an app using pull tools will a few base modules will be relatively easy
to
migrate.

What will probably bite many people in the ass will be the formation of
an
API in Turbine 3.0. In Turbine 2.0 things are pretty loosy goosy and
people
have nailed things on to the Turbine 2.0 structure to accomplish
something
because it wasn't possible without changing a lot of code, or there's
ten
ways to do the same thing. I hope that standard ways to accomplish
certain
tasks will emerge. The entire system will be pluggable from one end to
the
other so hopefully what we will end up with is set of interfaces with a
default implementation that should cover most things in a standard
application
 
> Knowing such details may have an impact on how I design and write an
> application using 2.x so that the migration to 3.0 someday would be
less
> painful.  

I really believe that the process of migration can mostly be passed off
to a
process in the TDK. Between a combination of adapter code and some
migration
tools that most people will be able to move there apps forward in less
that
a days work. The migrator will catch 95% of the cases and as more issues
come to light they can be accounted for in subsequent versions of the
migrator.
 
> Thanks.
> Dave
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tur...@ja...
> For additional commands, e-mail: tur...@ja...

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



---------------------------------------------------------------------
To unsubscribe, e-mail: tur...@ja...
For additional commands, e-mail: tur...@ja...