Re: Attributes 'Version and 'Body_Version

["Nick Roberts" <nickroberts@adaos.worldonline.co.uk>]

I think there's some mileage in the idea that it might be useful for
'Version and 'Body_Version to (be able to) return something more than just a
checksum (or the like). I think Tony Gair's comment hints at why.

Supposing an Internet web page is offering a download of a partition
(program) called Whizzo (which solves all your marital problems by
psychology).

Different potential users of Whizzo may well have different versions of the
partitions (which contain units) that Whizzo depends on. Suppose those units
are: Psychospeak; Technobabble; and Generally.Dodgy.Stuff. Each is in a
separate partition.

To support as many users as possible (before they jump off a bridge), Whizzo
has been built in multiple versions supporting the various versions of
Psychospeak, Technobabble, and Generally.Dodgy.Stuff, and a table is shown
on the web page allowing the user to select the correct version of Whizzo to
download. E.g.:

Psychospeak   Technobabble   Generally.Dodgy.Stuff     Whizzo
2f10e401      5ea109d0       4ea23310                  > 5a1b207a <
7bc195a2      d4216eee       40abba31                  > 8a90001b <
f9fa51ef      5201ac48       216b6d48                  > 21a68c5c <
6d33a902      5201ac48       39b278b7                  > d409b12b <
etc

Which is okay, but it would be nicer if the versions were in a slightly more
human-readable form. E.g.:

Psychospeak      Technobabble      Generally.Dodgy.Stuff     Whizzo
V:2 R:7 (472)    V:3 R:11 (1027)   V:Pub:1 R:2 (29)          > V:1 R:1
(10052) <
V:2 R:7 (479)    V:3 R:11 (1028)   V:Pub:1 R:2 (30)          > V:1 R:1
(10051) <
V:2 R:7 (480)    V:4 R:1 (2475)    V:Pub:1 R:2 (32)          > V:1 R:1
(10050) <
V:2 R:8 (20)     V:4 R:1 (2475)    V:Pub:1 R:2 (39)          > V:1 R:1
(10049) <
etc

The idea behind the versions shown here is that the build tool (source
controller, version manager, whatever) maintains a version and revision
number (which the user changes, and can enter prefixes for), and
automatically maintains an 'iteration' number (build number), and generates
the version string from all of these. But this is just an idea.

Recalling back to some of the comments made in this thread, there was the
suggestion that a unit could support multiple versions of a service unit,
which offered different levels of service.

I would suggest that this is best done (in Ada 95) by the technique of the
service unit exporting objects of a class (hierarchy) to its clients (via a
remote access-to-classwide type and a repository/directory/agency unit or
object).

This has to be a classic Ada 95 'pattern': the clients are versionistically
decoupled* from the servers; servers which add functionality can do it in a
totally forwards-compatible way (by deriving from the originally published
type, and exporting objects of the derived type); old clients are 'fooled'
into getting the old type (and service) they expect; new clients can take
advantage of the added functionality; an 'intelligent' client can test the
type of the object it gets, and perhaps adapt to the functionality the
object provides.

--
Best wishes,
Nick Roberts



*term obtained from the Technobabble unit (C) 2001 Technobabble Inc. All
rights reserved.

;-)