[V4RB] Auto-download of engines

[Shaun Wexler]

On Aug 25, 2006, at 3:29 AM, Ruslan Zasukhin wrote:

> The same ideas of binary compatibility present in MS COM.
>
> And they have idea of extension which I not like too much, but no  
> other way.
> If you need add new methods you must create NEW interface:
>
>     I_Table
>     I_Table2
>     I_Table3
>
> They even really name them in this way...

Actually, no.  You can use the existing COM too.  App1 might only know  
about the functions I_Table, I_Table2, and I_Table3, whose exported  
interface is declared as TableVersion_0, part of framework version  
"A".  Let's say that App3 is built against TableVersion_1 (providing  
the new functions for Table4 and Table5), and App2 is built against  
TableVersion_2 (providing the new function Table6), both of which are  
part of the binary-compatibility framework version "B", but the  
TableVersion_2 was later added in B v3.5, whereas TableVersion_1 was  
part of the original B v3.0 API.

The COM dispatch can implement all functions:

     I_Table     // TableVersion_0, available in frameworks A & B
     I_Table2    // TableVersion_0, available in frameworks A & B
     I_Table3    // TableVersion_0, available in frameworks A & B
     I_Table4    // TableVersion_1, available in framework B
     I_Table5    // TableVersion_2, available in framework B
     I_Table6    // TableVersion_2, available in framework B (v3.5 or  
greater)

All apps will vector thru the same COM, but both App1 and App3 are  
happily unaware that I_Table5 and I_Table6 even exist.  Because App2  
is built against v3.5 of framework "B", it must perform a runtime  
check for TableVersion_2 availability, and if the installed framework  
is too old, it can perform the download/upgrade itself if necessary,  
weak link, disable functionality, whatever...

-- 
Shaun Wexler
MacFOH
http://www.macfoh.com