tag:blogger.com,1999:blog-834134852788085492.post8405549386953859077..comments2024-03-02T07:59:30.808+01:00Comments on RealTime Data Compression: Dealing with library version mismatchCyanhttp://www.blogger.com/profile/02905407922640810117noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-834134852788085492.post-76561960846055804802017-07-27T18:48:39.891+02:002017-07-27T18:48:39.891+02:00These are pretty good points David,
maybe a #defin...These are pretty good points David,<br />maybe a #define could help to disable declaration of one APICyanhttps://www.blogger.com/profile/02905407922640810117noreply@blogger.comtag:blogger.com,1999:blog-834134852788085492.post-37111770145905312442017-07-27T09:13:55.127+02:002017-07-27T09:13:55.127+02:00Thinking about it a bit more, I now see the point ...Thinking about it a bit more, I now see the point of using the 'generic' api for advanced scenarios where a program wants to support multiple versions of the library. Very good explanation of the issues (I am not a C programmer).<br /><br />About supporting both, is my understanding correct that most programs will use either one (the specific) or the other (the generic) api? Mixing the apis seems to have no real use case, as soon as you call one specific api you risk a linker error.<br /><br />If I am a developer in a team that uses the generic API, it will always use it as a matter of policy, and I want to have a way to disable the specific api (i.e. by putting it behind an #ifndef) such that I can be sure that I (or my teammates :-P) never call one of the specific apis by mistake. Or maybe even put the two APIs into different headers?Anonymoushttps://www.blogger.com/profile/04007626658363210501noreply@blogger.comtag:blogger.com,1999:blog-834134852788085492.post-89095906838900367532017-07-19T00:49:05.630+02:002017-07-19T00:49:05.630+02:00> Most of developers overall and hence most you...> Most of developers overall and hence most your users are probably using Windows.<br /><br />This used to be true a decade ago, but these, I'm pretty sure that most of my users are working on Unix related platforms.<br />Note that my users are not typical GUI end-users, but rather programmers, and system administrators.<br /><br />My understanding from feedbacks : individual functions have an advantage when it comes to detect errors/mismatch at compile time.<br />generic function has an advantage when it comes to link to an arbitrary library version, although version mismatch is not magic and still require runtime checks.<br /><br />I'm likely to propose both interfaces in the `dev` branch soon, to continue the test.<br />An important point will be to determine which one feels easier to use.Cyanhttps://www.blogger.com/profile/02905407922640810117noreply@blogger.comtag:blogger.com,1999:blog-834134852788085492.post-27221306895857435162017-07-16T13:25:18.627+02:002017-07-16T13:25:18.627+02:00A few more random notes:
Most of developers overa...A few more random notes:<br /><br />Most of developers overall and hence most your users are probably using Windows. On Windows, it's usual to perform static linking, so in most of cases ZSTD will be static-linked. Moreover, these users prefer simplicity and reliability to advanced features we discussing here.<br /><br />When i use DLLs, i just perform GetProcAddress() which allows to dynamically check whether required function is present in DLL. In this case, application can accommodate earlier library release. But the automatic-linking style you assuming is probably much more widespread.<br /><br />Using library version to decide which parameters are available, will be broken once alternative implementations will arrive. In this case, generiс API may be used instead (as alternative to providing preprocessor constants corresponding to each parameter). Moreover, other languages such as Java, don't have access to C preprocessor, so each binding will either need to provide its own way to check available features, or you should provide a generic function-based way to do that.<br /><br />Bottom line: most of your audience will be happy with individual functions, although can live with generic ones. There are lot of unusual cases when generic APIs are preferable, but we may ignore them since they are pretty rare. But the case of automatic linking with DLL you mentioned, is really important.<br /><br />This means that generic API is required to allow DLL users to automatically link to various versions of library. Without generic API, DLL users will have to manually link to functions they need via GetProcAddress() or its equivalents.<br /><br />At this point, I think that you should provide both APIs, since you have important audience for both ones. But if you need to choose, i vote for generic API - this slightly beats single-version users, but anyway they are better to check return code of each set* call.Zedhttps://www.blogger.com/profile/17464441238899441016noreply@blogger.comtag:blogger.com,1999:blog-834134852788085492.post-74687328458817294142017-07-16T12:44:00.787+02:002017-07-16T12:44:00.787+02:00Citing your answer for old thread: "I don'...Citing your answer for old thread: "I don't think it's a good idea to support both (except maybe for a limited experimentation period). To ensure long-term maintenance, it will have to coalesce onto one implementation."<br /><br />I hope that later ZSTD will have thousands of users, i.e. developers using this library. This makes situation very different to CLS/CELS, which have only a handful of users.<br /><br />So, improved error detection of individual functions should be really helpful to your users and I think that you should implement it.<br /><br />As for generic API, it should depend on real needs. Perhaps provide GitHub Issue for it, so anyone who needs it, can vote up and write why. I think that such API may be useful for generic code, and may simplify other language bindings - in particular improve their forward compatibility, since binding for 1.10.0 will still work for 1.11.0, requiring only a few extra constants defined.<br /><br />I don't see any unusual problems for maintenance if you will end up supporting both.Zedhttps://www.blogger.com/profile/17464441238899441016noreply@blogger.com