>> Also, there needs to be an update strategy for applications. It is >> very helpful that a compatibility layer exists. For example, FB was >> designed with sdlpl 1.x, and as sdlpl 2.x was not compatible with it, >> or I didn't know how to do it, I finally had to write the "surf" sub >> and friends to be able to use both versions, and let distros upgrade >> smoothly. This creates problems. Or your new SDL needs to be parallel >> installable with the old one, and FB would be migrated to using the >> new one only months after the new one is released, to wait for >> propagation in distros. > > I think we can do the second one. Maybe we can seperate the SDL view code > from frozen bubble main logic so that we can swap SDL versions. Sort of like > an interface. Similar to how DBI does it. What do you think?
I think if you write your SDLX sugar layer and make it compatible with sdldl 2.x, then no need for such an interface, and all sdlpl applications can upgrade to using your new SDL+SDLX stuff without a code change. It seems better. -- Guillaume Cottenceau - http://zarb.org/~gc/
