tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mind Bridge <mindbridge...@yahoo.com>
Subject Re: [DISCUSS] Backward compatibility
Date Thu, 14 Aug 2003 09:31:11 GMT
The problem that I see is the following:
Tapestry is designed to be a reusable component framework. That means that its main advantage
is to allow accumulation of components and code that would allow fast future development.
Now, consider how this ties with what we are doing at the moment:
- disallowing old DTDs automatically means that the accumulated components CANNOT be used
with new Tapestry versions without manual modifications.
- making incompatible changes to existing components automatically means that code working
in one version WILL NOT necessarily work correctly in another. 
None of this is acceptable.
We have libraries (not apps) comprising several hundred thousand lines of code related to
Tapestry and a huge number of components. The transfer to each new version of Tapestry has
been a complete and utter pain, often taking several days work of the entire company and causing
bugs that we find only later. While this was somewhat okay for the early Tapestry versions
in the view of the larger picture, I think we MUST now draw the line where this will stop.

This is NOT a made up problem. It is deadly serious. At the very least we must have a backward
compatibility section of the contributor's guide (I can help with this if necessary) and adher
strictly to it. The people using the framework are reaching a critical mass and changes in
the names of the interfaces or the objects' behaviour like what happened in 2.2 (and to some
extent in 2.3) would simply not be tolerated by Tapestry's users.
What must happen is that you can take a 3.0 application, run it with the 3.1, 3.2, etc. frameworks
and be sure that everything will work.
At the same time, there is a demand for some changes and that must be handled in some way
(e.g. by completely denying such changes or having a mechanism to do them). Consider the example
I gave -- form listener invocations. The overwhelming desire was to change the default behaviour
of the listeners to delayed invocation. How do we handle this? Do we
- not make this change
- add a second listener binding for those listeners
- do the change using the mechanism that I suggested
- screw everything and do the change anyway.
Obviously, the second choice is the easy way out in this case, but it will not always be possible.
What would our standard approach be?

Geoff Longman <glongman@intelligentworks.com> wrote:

On the surface it kinda makes sense. But I imagine there would come a point
where configuration overhead would become a burdon.

What really prompts the -1 from me is that once people can mix and match the
behaviour of things, the next step will be mixing and matching DTD versions.
Say a library using the 1.3 DTD in an app using the 3.0 DTD. YIKES!

----- Original Message -----
From: "Mind Bridge" 
Sent: Wednesday, August 13, 2003 10:42 AM
Subject: [DISCUSS] Backward compatibility

> Hi,
> We have been discussing periodically backward-incompatible changes that
will make the framework more powerful. Needless to say, these changes are
great in the long term, but they do have a cost with respect to the
developers who are using older versions and want to switch to a new one.
This problem is bound to become more and more important as the number of
people using Tapestry increases. I would like to suggest an approach that
should 'untie' our hands to make some backward incompatible changes in
general. Here is a good example: the change in the form listener behaviour
(invoke immediately or delay) discussed a while ago.
> The idea is the following: have a standard component property called
'org.apache.tapestry.version-compatibility'. The value of the property
should be a number. It will represent the version which the code targets.
> When components introduce backward-incompatible changes in their
behaviour, they can check this property to decide how to behave. For
example, the code that invokes the form listeners can check whether the
version is <= 3.0 and invoke them immediately, or if it is >= 3.1 (for
example) it can perform delayed invocation unless specified otherwise. The
result of the check can be stored in the component at load time, so it will
have no other bearing on performance.
> The following order can be used to search for the property value:
> component/page (this will be the enclosing component/page in cases like
the above)
> namespace
> application
> ... the rest of the standard property search order
> This will allow, for example, a library and its components to have
3.0-specific code, while the rest of the application is designed for 3.3 or
sth like that.
> Clearly, this would not help in all cases, but it will definitely make
some incompatible changes much easier to make.
> Does this make sense?
> Best regards,
> -mb

To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message