599491 - Should API versioning and BugCompatibility be unified?

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Steven Johnson]

In theory, API versioning and BugCompatibility are orthogonal issues: the first is about making names visible (or not), the second is about changing functionality.

In practice, though, they tend to go hand-in-hand: a given SWF/ABC is likely to be built to expect a single (API+BUG) set in tandem, so combining the settings is a sensible way to reduce confusion and possible error.

Furthermore, API versioning is (currently) more granular than BugCompatibility; API-versioning can be specific by a SWF version (for Flash), *or* a namespace-specification in the app manifest (in AIR apps). BugCompatibility, on the other hand, is (currently) tied only to SWF version.

Comment 1

[Jason Williams]

AIR is using the versioning to do bug compatibility comparisons as well.  For eaxmple: 		

if (core()->GetCorePlayer()->GetPlatformAPIVersion() >= CorePlayer::AIR_2_0) {
 // something interesting
} else {
  // Old broken behaviour

Comment 2

[Steven Johnson]

(In reply to comment #1)
> AIR is using the versioning to do bug compatibility comparisons as well.  

Oh. Goody. That definitely bumps up the priority, then -- having two ways being used for this is a recipe for pain.

Comment 3

[Lars T Hansen]

(In reply to comment #0)
> In practice, though, they tend to go hand-in-hand: a given SWF/ABC is likely
> to be built to expect a single (API+BUG) set in tandem, so combining the
> settings is a sensible way to reduce confusion and possible error.

I think what you're saying is not that versioning and bug compatibility should be unified (and I don't even know what that would mean), but that the APIs we offer from Tamarin to the host code should guarantee that dependencies between them are not violated / should allow settings for both to be specified together to ensure that they are synced.

> 
> Furthermore, API versioning is (currently) more granular than
> BugCompatibility; API-versioning can be specific by a SWF version (for
> Flash), *or* a namespace-specification in the app manifest (in AIR apps).
> BugCompatibility, on the other hand, is (currently) tied only to SWF version.

Well, the API we offer ties it to a SWF version, but that's because the only host code that has asked to use bug compatibility is the Flash Player.

Comment 4

[Steven Johnson]

(In reply to comment #3)
> I think what you're saying is not that versioning and bug compatibility should
> be unified (and I don't even know what that would mean), but that the APIs we
> offer from Tamarin to the host code should guarantee that dependencies between
> them are not violated / should allow settings for both to be specified together
> to ensure that they are synced.

Yep, a better way of stating it. But, as it turns out, probably also to migrate existing (incorrect) usage of API versioning for bug checking to use BugCompatibility instead.
 
> Well, the API we offer ties it to a SWF version, but that's because the only
> host code that has asked to use bug compatibility is the Flash Player.

This is true; I assert that AIR and Flash are close enough that we have a compelling interest in having them use the same mechanism.

Comment 5

[Steven Johnson]

Claiming this bug -- I think we are going to want to settle on a single API for specifying "compatibility", and that the specifier is likely to be what is now the "API version" as it is a strict superset of SWF version.

I'm going to hold off working on it for a few days, as progress will become much easier once the various new API versions, and the data-driven ASC.jar, both land in mainline code repositories.

In the meantime, comments / objections welcome.

Comment 6

[Steven Johnson]

Attachment: Sketch at cleaning up API versioning as prep work

Comment 7

[Steven Johnson]

Comment on attachment 490728 [details] [diff] [review]
Sketch at cleaning up API versioning as prep work

Whoops, hit enter too early.

Patch can't land until/unless we make a version of asc.jar without hardcoded versions, but the idea is:

-- api-versions.xml no longer requires explicit release or version ids; they are now generated implicitly. version numbers now start at 0, not 660. 

-- Names of versions api-versions.xml are now all of the form "SWFxx" or "SWFxx_AIRxxx"; idea is that our versions are always either a specific version of SWF, or a specific SWF-and-AIR-namespace. (Exception for "SWF10_FP10_1" which is likely to be kept for historical reasons.) I considered keeping the old names, and/or aliasing the old names, to avoid churn in the codebase, but IMHO better to bite off this nasty bit all at once.

-- apivergen.as exports the values to api-versions.h, so we should (in theory) be able to replace the definitions in splayer.h with references to these.

-- since first version number is now 0, all the weird "660" and api_start stuff goes away.

Theory behind all this is that this new unified namespace/enum set in api-versions.xml and friends will be the single specifier for both api versioning and bug compatibility.

Asking for feedback for now; can't review as I can't test (or even compile!) without a non-hardcoded version of asc.jar, sigh...

Comment 8

[Jeff Mott]

Sounds like a good way to resolve things.  Have you had any thoughts about how this will apply to bug compatibility in AVM1 code?

Comment 9

[Stan Switzer]

Changing the numbering would entail changes to the compiler too, I believe, because the compiler recognizes the legacy versioning scheme and plunks in the old 660-based numbers for them.

BUT if we change the compiler then we introduce an undesirable sensitivity between the compiler version and OLDer versions of the runtime so that we have to use older compilers to build, say, patches to older versions.  And I don't believe we have had to do that so far, at least not on account of versioning (maybe on account of new opcodes or something).

Comment 10

[Stan Switzer]

(In reply to comment #9)
> Changing the numbering would entail changes to the compiler too, I believe,
> because the compiler recognizes the legacy versioning scheme and plunks in the
> old 660-based numbers for them.

But the compiler could continue using the old 660-based versions (and stay compatible) for the legacy version tags if we eliminate all of them from the player builtins. That would be awesome (and about time)!

Comment 11

[Steven Johnson]

(In reply to comment #8)
> Sounds like a good way to resolve things.  Have you had any thoughts about how
> this will apply to bug compatibility in AVM1 code?

Not yet, unfortunately; I'm trying to approach this in bite-sized steps, and I don't them that AVM1 has an equivalent to CodeContext that I can leverage. We might have to continue to have stupid "toplevel SWF wins" behavior for AVM1 fixes, but I'd like to obscure that inside an API at least. (That's arguably outside the scope of this bug though since this is only about AVM2.)

(In reply to comment #9)
> Changing the numbering would entail changes to the compiler too, I believe,
> because the compiler recognizes the legacy versioning scheme and plunks in the
> old 660-based numbers for them.

ChrisT and JeffD have been working on revamping asc to not need the version numbers to be "baked in"; I'm not sure what the status of this work is, but it's a precondition to improving the situation. I believe the design is such that we can change these numbers without affecting existing external content.