From: Daniel M. G. <dmg...@uv...> - 2006-06-20 16:29:35
|
Fulvio> I subscribed to this list from its start, but I never posted here Fulvio> because I am not developing pano12, at the moment. Fulvio> Anyway, I have read about branching the library because the new Image Fulvio> struct is not compatible with older programs like PTStitcher. Fulvio> I think that there is another option: keep the older structure and code, Fulvio> change name to the new Image struct (something like "ImageEX"...) and Fulvio> write new functions that use the new struct with a different name, for Fulvio> example from "FuncName" to "FuncNameEX". With a little luck we could Fulvio> find some code that will not need to be duplicated so this solution Fulvio> would save some work and a lot of confusion for users. Fulvio> Older programs would keep calling the old interface and would keep working. Fulvio> Newer programs would call the new interface and use the new structure. Fulvio> BTW, you could use a trick used in the Windows API: the first field of Fulvio> the struct could contain the struct size. A caller using a newer version Fulvio> of the struct would pass a larger value and the called program would Fulvio> know that it is receiving a different version of the struct. Fulvio> I don't know if this solution is practical since it is a long time that Fulvio> I do not look at the code, but it should save some work compared to Fulvio> branching. In principle it is doable. I was looking at the Image struct, it does not have a field that will let us know what "version" it is, but one can be added (there is a field with the name of the image taking 256 bytes, it would be easy to steal 2 or 4 bytes from it to use for this purpose). I would rather create a pointer using those bytes to another area, so the struct remains the same size (to make sure that arrays keep working). While this allows the library to continue offering backwards compatibility it makes it a pain to maintain. The current code of PTcommon and PTmender look the way they do because I reproduced the Helmut's code. But it needs to be cleaned up and improved. By forcing backwards _binary_ compatibility we are basically forcing the developers to spend an unnecessary amount of time having to make sure that the changes don't break it. And what is even worse, _I cannot_ run PTstitcher because it is not even supported in my development platform (OS X). Also, who uses the library directly? * Helmut's applications * Hugin Anything else? Maintaining binary compatibility is very difficult (but not impossible), and in my opinion it is not worth it. It makes programming more convoluted, testing more difficult, and it removes some of the fun from contributing to the project. -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |