Curl RTE :: Backward Compatibility ...

13 Replies Last post: Jul 31, 2008 10:22 PM by Duke

Curl RTE :: Backward Compatibility

Jun 30, 2008 1:31 AM

URPradhan 141 posts since
Mar 6, 2008

Does a particular version of Curl RTE supports backward compatibility ?

Means, suppose the end user has installed Curl RTE API version 7.0, and he/she has browsed a site having a curl applet written for API 6.0.
In this situation RTE prompts for installing another (old) version of RTE ie, 6.0 on his/her m/c (which I do not like at all and its difficult to educate end users of your applet with sufficient reason). Unless he/she installs that old version, he/she will not be able to run that applet

Ideally its against any products minimal feature (I believe so). If I have API v7.0 why I need another old RTE having API v6.0? The higher API versions should be backward compatible.
Is there any sufficient reason behind it ?

Personally what makes me frustrating is that, I have installed v7.0. And whenever I browse any curl applet v6.0, it prompts me to install API v6.0

Then as a developer, to make our applet future proof, we have to mention the current and future versions (omg ! how can we know the future api version

) of curl API in the applet herald !

Can any expert will clear my doubts ?

Tags: rte, backward, compatibility

cbarber 115 posts since
Sep 27, 2007

1. Re: Curl RTE :: Backward Compatibility Jun 30, 2008 8:11 AM

The problem is that there really is no way to make a set of libraries perfectly backward compatible without seriously restricting your ability to change them. You cannot even introduce a new class in an existing package without potentially breaking someone's code. For instance, let's say that we were to add a new class Foo to the CURL.GUI.BASE package, but someone else has introduced a class with the same name in another package, then the following code would break:

{import * from CURL.GUI.BASE}
{import * from OTHER-PACKAGE}
{Foo} || ambiguous name error

To avoid this and many other issues, we allow different versions of the RTE to be installed side-by-side. This is actually an extremely important feature for Enterprise customers. They can deploy applications using different versions of the RTE and know they don't have to retest older applications under a new RTE until they decide to actually upgrade them to the newer version.

While this is somewhat annoying for end-users to have to install an older version, there is no reason they should not do so, and I would strongly suggest anyone using the 7.0 beta to also install 6.0. If you have the 7.0 IDE installed, you can go to the Debugger pane of the Curl Control Panel and select the checkbox to attempt to run 6.0 applets under 7.0. This setting will only be in effect until you shut down Curl and may not work for all applications.

Although, we do allow you to put multiple version numbers in Curl applet heralds:

{curl 6.0, 7.0 applet}

We only allow you to deploy pcurl files under one version, so you would need to either avoid pcurl or specially configure your manifests to support it, e.g.:

{curl 6.0, 7.0 manifest}
{delegate-to A-6-0, location = "a-6-0.mcurl"}
{delegate-to A-7-0, location = "a-7-0.mcurl"}
 
|| a-6-0.mcurl
{curl 6.0 manifest}
{manifest A-6-0}
... 6.0 pcurl files ...
 
|| a-7-0.mcurl
{curl 7.0 manifest}
{manifest A-7-0}
... 7.0 pcurl files ...

However, most developers don't like to support more than one API version at a time, so few take advantage of this feature.

Rams 17 posts since
Jun 5, 2008

2. Re: Curl RTE :: Backward Compatibility Jul 17, 2008 9:04 PM

in response to: cbarber

My 2 cents and a couple of questions -

I think the "backward compatibility (or the lack thereof) could be a real issue....I am not sure whether companies like the idea of spending on IT projects with no real "value add" to the business.

If we install applications this year with RTE 6.0 and Curl stops supporting this version .. say in a couple of years, doesn't that mean that we will be forced to "upgrade" the applications?

And what does this "upgrade" involve ?

Thank you

-Rams

carl 74 posts since
Oct 17, 2007

3. Re: Curl RTE :: Backward Compatibility Jul 17, 2008 9:47 PM

in response to: Rams

I think it's somewhat in error to call it a lack of backwards compatibility. It's actually improved backwards compatibility, because it goes to great lengths to preserve the original environment that your code was running in. It's more that the developer makes an explicit choice to support a new version and deal with any incompatibilities that result at that time. I'm using a somewhat vague definition of environment here, since I think this is actually one instance of a broad issue.

Contrasting with this is the more common system, which is in a way backwards -- a new version of the environment comes out and simply breaks existing code, so either the developer is forced to upgrade version support at that time, possibly removing support for older versions, or doesn't bother to and so users have to figure out for themselves which versions they can still use this hypothetical application with. I've seen older applications that I've used -- this is just from a personal perspective -- effectively die off when OS updates finally break something critical, and in such cases it's generally not possible to run older instances of the environment to keep the old code alive. In Curl's case, it is possible.

Version support is certainly an issue, but equally so for almost any product. Microsoft supports some versions of Windows but not the oldest ones. Any vendor will naturally have a window of support for a product -- the question is mostly whether that window is reasonably wide.

Duke 154 posts since
Oct 17, 2007

4. Re: Curl RTE :: Backward Compatibility Jul 17, 2008 11:24 PM

in response to: Rams

To be concrete (but hypothetical) the situation you are talking about is something like, in the year 2015 Curl might stop supporting Curl version 3.0. The impact of that would be that in 2016 when Microsoft releases Windows XX it might be that users who have upgraded to XX might no longer be able to use Curl version 3.0 applets.

But if your business wants to use XX, then you would have to upgrade from 3.0 to a supported version of Curl. In terms of the impact on your code, that would probably be minimal. It has certainly been minimal in the past to upgrade an applet from 3.0 to 6.0, because there have been very few API changes that have required changes to the old code. Your users would have to install the supported version of the RTE, and you would have to have a new license for the supported version, which seems fair since you need the new functionality of working with XX.

URPradhan 141 posts since
Mar 6, 2008

5. Re: Curl RTE :: Backward Compatibility Jul 17, 2008 11:46 PM

in response to: Duke

I believe, its for the s/w vendor, who maintains versions of the application, to test thoroughly for backward compatibility (upto window period), before distributing a new version. And I believe most /sw vendors works with this model including Microsoft and we call it "XYZ s/w is EXTENSIBLE". So, at the end of the day its ONLY the end user will get benefit without cluttering of 4-5 versions of the same application/RTE. And any 3rd party wants to build any s/w then he/she has to mention the Requirements (both system and s/w). We have been grown with this model and I believe it will continue in future too.

cbarber 115 posts since
Sep 27, 2007

6. Re: Curl RTE :: Backward Compatibility Jul 18, 2008 8:42 AM

in response to: URPradhan

No operating system is %100 backward compatible with past versions, and programming APIs are even less so, so I am not sure what you are talking about. There are plenty of Windows XP programs that do not run under Vista (I know because I have some on my laptop at home :-().

The point of our versioning model is that we want Curl developers to have some assurance that their applications will only be run in an environment that is close to what the built and tested on. Deploying an application for a new version simply requires changing the version numbers in your Curl heralds and redeploying, so it is hardly a big deal.

Duke 154 posts since
Oct 17, 2007

7. Re: Curl RTE :: Backward Compatibility Jul 18, 2008 8:44 AM

in response to: URPradhan

Curl is extensible in your sense, in terms of the service packs within a major API version, like 5.0.0, 5.0.1, 5.0.2, etc. Different major versions, e.g. 4.0 versus 5.0, can have some incompatible API changes or other functional changes, so that it will generally be easy to upgrade your applets from version N to N+m, but you will want to do a full QA examination of your applet when doing a major upgrade.

As for the clutter of 4 or 5 different versions, they are each only taking up less than an $0.01 amount of disk space, and the user and the developers of applets using the earlier versions don't have to worry about problems and bugs possibly introduced if somehow their applet was going to be forced to run with the later major Curl versions that the developer never had a chance to use to do a QA of their applet.

wbardwell 46 posts since
Oct 31, 2007

8. Re: Curl RTE :: Backward Compatibility Jul 18, 2008 9:25 AM

in response to: Duke

The idea is that we are trying to guarantee that an applet will work because it will be running under the same system that it was QA-ed against. The cost of this is that users may need to install older RTEs if the applet provider hasn't QAed with a new version and marked it as running under that new version. This contrasts with Windows and most other runtime environments in which you just can't tell if an application will work on a newer OS, and in fact we have certainly had to add fixes for every new version of Windows that has come out. NT, 2000, XP and Vista are all slightly different, and the Curl RTE has at least a few bits of code hiding each those differences. Even worse, IE5, IE6, IE7, and IE8, Firefox 1.0, 2.0, 3.0 have also each required code changes. But old Curl applets can continue to run under the same code (except for security and platform support, and generally conservative bug fixes that are in the patch releases) until (if ever) the applet author re-QAs their applet to make sure that it works under a new version. We have tried in the past to make one RTE that supported two API versions, and it was very hard bordering on impossible, and took way more time and effort than doing what we do now, and as machines get more disk and memory and bandwidth gets cheaper it becomes less and less worrisome to have extra versions of the Curl RTE on the machine.

Rams 17 posts since
Jun 5, 2008

9. Re: Curl RTE :: Backward Compatibility Jul 21, 2008 11:38 AM

in response to: wbardwell

I appreciate all the input. I see that this "multiple RTE versions side by side" approach has a lot of support inside Curl..... which is fine..... if it has been determined that the buyers will like it.

I think that most IT shops using IBM mainframes may expect 'development tools' to be backward compatible.....

Based on my experience, it is very rare if ever, any mainframe applications' source code needs to be "touched" when IBM releases a newer version of their OS or a newer compiler and libraries. It is very common in these shops to see applications developed in early 90's are still in use with no changes to the source code and working fine with the latest OS / compiler / run-time libraries.

So, if one is to suggest building a "rich front-end" applications using Curl, these IT shops are probably going to expect similar compatibility - i.e. whatever is executing under version n.0 continues to work with version (n+1).0, without having to "touch" the source code. The only action from the IT will be distributing the new (replacement) RTE to the users after making sure it does not break any "mission critical applications".

I also think such an approach would help version support management relatively easier for Curl...

Also is it possible that the RTE automatically detects earlier version numbers in the heralds and take care of these on the fly? Sure if someone added a class with the same name used in the later version, there will be an issues. However these things can be avoided using naming standards enabling most applications to work fine ... right?

Thank you

-Rams

cbarber 115 posts since
Sep 27, 2007

10. Re: Curl RTE :: Backward Compatibility Jul 21, 2008 1:28 PM

in response to: Rams

We do know that our customers like our versioning story. We have found that some of our customers are reluctant to push out even a fully backward-compatible patch release of the Curl RTE without extensive testing of their applications, so it is no surprise that some may not want to have to retest all of their applications written for a previous API whenever they install a version of the RTE supporting a new API.

I don't know anything about code libraries on IBM mainframes twenty years ago, but the world has changed a good deal since then. Furthermore, I can recall many occasions, and some fairly recent ones, working with Unix, Windows and Mac platforms where changes in the OS, APIs or compilers required significant changes to code when upgrading. It is much easier to maintain backward compatibility with much more restrictive statically compiled languages lacking dynamic features. When you throw in features like runtime reflection and code evaluation then any API change whatsoever could break some program or another.

Our current model allows multiple version of the Curl RTE to be installed side-by-side. The master version of the RTE, which is always the most recent version, will recognize version numbers in Curl applets and dispatch the applet to the appropriate older installed version of the RTE or show a message indicating that a different RTE version needs to be downloaded and installed to run the applet. This does not require IT to touch applications when new versions of the RTE are installed. They do not need to modify the code until they decide to discontinue use of an older version of the RTE, at which point they only need to update the Curl heralds to the new target version, which can be done automatically by the Curl IDE.

I don't know what kind of naming convention could ensure backward compatibility. Are you suggesting something like all new methods added to an existing class should have a prefix like "curl-6-0-"? How else can you be really sure that no one may have used some name in a subclass? For instance, I recently suggested to a colleague that we should consider adding a 'filter' method to the 'Dequeue-of' class. While that seems fairly safe, doing so could break any user-defined subclass of Dequeue-of that defines a member with the same name but a different signature. I know of no language or library that uses such naming conventions. Our current versioning story ensures that no one will make use of a new version of the Curl API without changing their heralds. This allows us to make API changes such as this and know for sure that it will not break any already deployed applications. Developers that want to take advantage of the new API must change their heralds, retest and redeploy before their customers will have the chance to discover incompatibilities.

The key point to understand is that unlike other RIA platforms Curl applications are compiled dynamically on the client. While this provides for great flexibility and power, it also means that without our approach to RTE versioning it would expose end users to language or API compatibility issues that normally only developers would ever encounter.

Christopher

rhh 29 posts since
Oct 12, 2007

11. Re: Curl RTE :: Backward Compatibility Jul 31, 2008 12:28 PM

in response to: Duke

I particularly agree with the above comments by Carl and Duke. Curl is backward compatible, to a greater extent than many (most?) other platforms. The debate here is really about the implementation of backward compatibility in Curl. Instead of packaging up support for every past version of the Curl API in one RTE installer (which we could have done), we have an architecture where if you have, say, only the version 6.0 RTE installed and you want to run a version 5.0 applet, you will need to install an additional component in your Curl installation. You might think of this component as a "version 5.0 compatibility pack" but we call it the "version 5.0 RTE." The complete separation of the 5.0 and 6.0 implementations, as opposed to trying to merge them together in one code base with conditionals, cumbersome naming conventions, etc., gives customers a much greater assurance that they will get predictable behavior for their existing applications as the Curl platform evolves.

-Bert

URPradhan 141 posts since
Mar 6, 2008

12. Re: Curl RTE :: Backward Compatibility Jul 31, 2008 9:29 PM

in response to: rhh

Thank you Bert for explaining in a simple way.

So, as you said if I have installed RTE 6.0 and want to run an Curl applet of v5.0 then, RTE v5.0 will be installed, which you are saying a compatibility pack of v5.0 for v6.0 (technically). So is it just a compatibility pack of v6.0 or exactly a standalone installer for v5.0 ? Means its like installing a fresh copy of v5.0 ?

Thank you

Duke 154 posts since
Oct 17, 2007

13. Re: Curl RTE :: Backward Compatibility Jul 31, 2008 10:22 PM

in response to: URPradhan

The same installer is used, but it acts like a compatibility pack if there is a higher numbered Curl version already installed. The highest numbered Curl version you have installed acts like the "master", and it determines when the "compatibility packs" are needed to run a particular applet. The browser plug-ins , and also the Control Panel, come from the highest number installation.

If you are installing both 5.0 and 6.0 (for example, or any two versions), you use the same 2 RTE installers regardless of which order you install them in, and the end result will be the same regardless of the order of installation. The 6.0 installation will end up as the master version.

Curl RTE :: Backward Compatibility

Jun 30, 2008 1:31 AM

Actions

More Like This