2008/10/9 Rick McGuire <[EMAIL PROTECTED]>: > David's questions yesterday about RXSHV_PRIV pointed out a deficiency > in the new APIs. On the interpreter instance APIs, we really should > have APIs for checking the interpreter version and language level. > Fairly easy to add, but how should the information be returned? It > would be nice if we could come up with a binary format that allowed > for easy level comparisons, but that might be tricky. I think both > language level and interpreter level need to be provided because they > don't necessarily bump together. For example, with 4.0.0, the > language level is 6.03. Current plan is to come out with a minor > release shortly after 4.0.0 (4.0.1 probably) that will include fixes > and the repaired orxscript support. orxscript is not really a > "language" feature, so the language level might stay at 6.04. > > For a binary format, we could do what's done with IP addresses and > store each digit in a separate nibble. Thus the next release would > have an interpreter version of 0x00040000 and the language level would > be 0x00000603. These constants would allow an easy "is this level > greater than or equal to" check to be performed.
If an Oorexx-devel newbie may jump in for a moment (fools rush in, etc...) I'm not sure if the IP address analogy is right; IPV4 address are stored as 4 octets/bytes, and traditionally written as 4 decimal numbers (which of course can be expressed in hex or octal if desired). Your scheme seems more of a BCD encoding. But it's not clear to me if these are true decimal digits, and how they map to the nominal interpreter and language levels as they might appear in documentation. So if the interpreter level gets to 9.0.0 encoded as 0x00090000, what is the next major version? Would it be 10.0.0 encoded as 0x00100000, or 0x000a0000 or...? Also not clear to me is why interpreter level 4 point something is 0x0004xxxx, but language level 6 point something is 0x00006xx. If these are independent binary values, with the expectation for both that there can be "point" levels, shouldn't they both have the same number of places after the first point? Well, the bottom line seems to me to be that a program needs to be able to do a binary comparison between what it knows is a level that supports the features it needs, and the level of the running software. History is chock full of failures of this sort of thing, on VM, MVS, and many other systems, typically because the canonical compare was just not well thought out. (Just recently I've seen the situation where the Top Secret security product has a version string like 8SP03 for version 8 Service Pack 3, but 120SP05 for Version 12.0 Service Pack 5. Easy for people to parse; much trickier for a program to get right.) Assuming there is upward compatibility "forever", then the simple compare has to work "forever". Mostly this means making sure it really is binary, and that there is plenty of high order room for increasing version numbers, both of which I think you've done. But are there endian issues here? Best to make the data type make that clear. The other approach is, as MVS and VM have both done over the years, to provide feature bitmaps. But that's another can o' worms. Sorry for a wordy first post on a minor topic. Mostly I'm just reading and catching up. Tony H. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
