Question: Turbine 3 Release schedule/Features

[Brian McKendrick <bm...@n2bb.com>]

I am in the process of doing diligence on Turbine as a platform for my company's thin client applications.  I have not found much information on Turbine 3's release schedule or many of it's real improvements.  I will find it difficult to recommend porting our apps once to Turbine 2.x, and then again to Turbine 3.
 
Thanks in advance for any info.
 
bhm

RE: Question: Turbine 3 Release schedule/Features

[Gary Bisaga <ga...@maximus.com>]

I mostly support what Eric writes. Although our situation is different, we
are just in the throes of deciding whether to use Turbine, and many of the
same reasons lean in its favor. I would add to all that Eric wrote one nice
feature: the Turbine developers have done their design with close attention
to maintaining interface/implementation splits. There are many things about
the standard "as-downloaded" Turbine web application that we need to change
because of business requirements, sometimes with very non-trivial changes.
However, in most cases all we need to do is subclass one of the
implementations; at worst, we just need to rewrite an implementation but
maintain the interface. Nice. This is a far cry from a framework where all
accesses are done directly to a class implementation.

That having been said, I cannot say that I agree with the push (so to speak)
toward using the Pull model. My experience has shown that, at least in many
situations, a pure Pull model is harder to work with. I hasten to say that I
also don't advocate a pure Push model as demonstrated by the sample Turbine
app. Rather an "in-between" model where an intermediate registry maps
between a "page" and the associated classes and templates. Our user
interface designers don't see java code:  they see the registry and the
templates, that's all. Yes, sometimes java developers have to be involved in
making changes, but for some things they ought to be involved. Changes to
things like page flow, content, and layout can still be made without Java
developer help, by modifications to registries.

Thus, the user interface people own the templates, the java coders own the
java code, and the registries are sort of an in-between, jointly owned by
both. A large project using this model I worked on (6 user interface people,
15 programmers)worked fine; in fact the problems we had were when people put
code (pull model, I note) into the JSPs.

I'm not saying the Pull model never works, just that I certainly hope that
the Push model doesn't become passe or otherwise non-supported in future
versions (3.x?) of Turbine. In fact, the freedom to do Push or Pull is
exactly the kind of reason I advocate Turbine; I seems to me (a relatively
new Turbine aficionado) a Pull mandate would be very non-Turbine-like.

Thanks for listening.

<>< gary

-----Original Message-----
From: Eric Dobbs [mailto:eric@dobbse.net]
Sent: Friday, February 01, 2002 2:54 PM
To: Turbine Users List
Subject: Re: Question: Turbine 3 Release schedule/Features


On Thursday, January 31, 2002, at 09:02  AM, Brian McKendrick wrote:

> I am in the process of doing diligence on Turbine as a platform for my
> company's thin client applications.  I have not found much information
> on Turbine 3's release schedule or many of it's real improvements.  I
> will find it difficult to recommend porting our apps once to Turbine
> 2.x, and then again to Turbine 3.

There isn't a release schedule for Turbine 3.

Your question suggests that you may be new to opensource development.
If I've guessed that incorrectly, then some of this will be stuff you
should already know.


Let me offer our business rationale for choosing Turbine.

We chose Turbine just over a year ago, while version 2.1 was being
polished for release.  At the time we began, we were in the midst of
a typical "build vs. buy" debate.  As an opensource project, Turbine
falls somewhere between those options.  You don't have to buy it, but
you do have to invest some development time to really make it work
for you.  We had already paid to build a proprietary framework, but
budgets were cut before it was completed.  We couldn't afford to
finish it (and to maintain it, for that matter) with our small
development team.  And with our tight budget we couldn't afford the
"buy" option.  Turbine was a perfect fit in our situation.  It was
radically more mature than our own framework offering features we had
not even discovered we needed.

In choosing any system you face the risk of having to update your
application as that system evolves over time.  This is not something
unique to turbine, or even to opensource.  Evolution of the framework is
a risk.  In the case of a commercial vendor, you have some assurance
that they will make the migration to the new version graceful.  But
there are many cases where businesses have been burned by that
assumption.

There are some aspects of Turbine that mitigate these risks.

Apache and Jakarta have excellent reputations for production quality
development and has good brand recognition.  Turbine inherits some of
that intangible benefit since it's a Jakarta project.

There is a very active community of developers who have demonstrated a
long-term commitment to the project.  Most of them also depend on having
Turbine work for their own production systems.  By their own self
interest there will be a migration path from v2 to v3 once v3 is
sufficiently stable to justify migrating the production applications.

Because the development is open, we can influence the next release by our
contributions, both in code and conversation.  We have far more direct
involvement about what will be in the next version of Turbine than we
would with a commercial vendor.

This doesn't come for free -- your developers have to spend the time to
keep up with the Turbine development.  But in our case we've seen an
exceptional return on that investment.

You happen to be coming to Turbine at an especially good time.  Version
2.2 is coming very soon (from other threads on this list "soon" could be
within weeks.  There's no official schedule, so be aware of that risk.)
This will be an important step in the migration to T3.  One of the
differences between T2 and T3 is that some components have been decoupled
in T3 (specifically Torque and Fulcrum).  Turbine 2.2 will also use those
decoupled components.  It is possible that by the time you begin your
development you will have less "migration" to worry about between T2.x
and
T3.

Lastly, if you do choose Turbine, you should learn all you can about the
Pull model, because that is the preferred method of building turbine apps
and will definitely be supported in T3 (thereby making the migration
easier).

Hope that helps, but you have to decide for yourself if the risks of
using
Turbine are better or worse than your alternatives.

-Eric

--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Question: Turbine 3 Release schedule/Features

[Eric Dobbs <er...@dobbse.net>]

On Thursday, January 31, 2002, at 09:02  AM, Brian McKendrick wrote:

> I am in the process of doing diligence on Turbine as a platform for my 
> company's thin client applications.  I have not found much information 
> on Turbine 3's release schedule or many of it's real improvements.  I 
> will find it difficult to recommend porting our apps once to Turbine 
> 2.x, and then again to Turbine 3.

There isn't a release schedule for Turbine 3.

Your question suggests that you may be new to opensource development.
If I've guessed that incorrectly, then some of this will be stuff you
should already know.


Let me offer our business rationale for choosing Turbine.

We chose Turbine just over a year ago, while version 2.1 was being
polished for release.  At the time we began, we were in the midst of
a typical "build vs. buy" debate.  As an opensource project, Turbine
falls somewhere between those options.  You don't have to buy it, but
you do have to invest some development time to really make it work
for you.  We had already paid to build a proprietary framework, but
budgets were cut before it was completed.  We couldn't afford to
finish it (and to maintain it, for that matter) with our small
development team.  And with our tight budget we couldn't afford the
"buy" option.  Turbine was a perfect fit in our situation.  It was
radically more mature than our own framework offering features we had
not even discovered we needed.

In choosing any system you face the risk of having to update your
application as that system evolves over time.  This is not something
unique to turbine, or even to opensource.  Evolution of the framework is
a risk.  In the case of a commercial vendor, you have some assurance
that they will make the migration to the new version graceful.  But
there are many cases where businesses have been burned by that
assumption.

There are some aspects of Turbine that mitigate these risks.

Apache and Jakarta have excellent reputations for production quality
development and has good brand recognition.  Turbine inherits some of
that intangible benefit since it's a Jakarta project.

There is a very active community of developers who have demonstrated a
long-term commitment to the project.  Most of them also depend on having
Turbine work for their own production systems.  By their own self
interest there will be a migration path from v2 to v3 once v3 is
sufficiently stable to justify migrating the production applications.

Because the development is open, we can influence the next release by our
contributions, both in code and conversation.  We have far more direct
involvement about what will be in the next version of Turbine than we
would with a commercial vendor.

This doesn't come for free -- your developers have to spend the time to
keep up with the Turbine development.  But in our case we've seen an
exceptional return on that investment.

You happen to be coming to Turbine at an especially good time.  Version
2.2 is coming very soon (from other threads on this list "soon" could be
within weeks.  There's no official schedule, so be aware of that risk.)
This will be an important step in the migration to T3.  One of the
differences between T2 and T3 is that some components have been decoupled
in T3 (specifically Torque and Fulcrum).  Turbine 2.2 will also use those
decoupled components.  It is possible that by the time you begin your
development you will have less "migration" to worry about between T2.x 
and
T3.

Lastly, if you do choose Turbine, you should learn all you can about the
Pull model, because that is the preferred method of building turbine apps
and will definitely be supported in T3 (thereby making the migration
easier).

Hope that helps, but you have to decide for yourself if the risks of 
using
Turbine are better or worse than your alternatives.

-Eric

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>