Re: Message negociation
Steve Lhomme <[email protected]>
| Newsgroups | gmane.comp.multimedia.media-api |
|---|---|
| Message-ID | <[email protected]> |
Artem Baguinski wrote: > if every time the main API changes all plugins are rebuilt as well - you > don't have to do that. applications don't have to be rebuilt because it > doesn't matter for them if the pointer they receive actually points to > larger structure then they know about. Well, my point is *exactly* that knowning the size of the structure, you know there are less, equal or more callbacks than you handle. On your HD (UNIX) you can have version 3.5 of the library that is also a virtual link as verion 3.0, 2.3 and 1.0. And it will work for all applications dynamically linked with one of them. No need to rebuild anything. > if the goal of this library / api is to provide widely accepted and used > standard it shouldn't change to often anyway. come up with consistent > version numbering scheme and release policy which will make life of > binary packages maintainers easy, e.g.: I'm talking here with the experience of Matroska. It is hard for a project (this API for example) to succeed without any acceptance from the others and input from many people. And either you work silently and think about everything from the start, or you release intermediate versions that are subject to majors changes that could break anything... In the first case it's very likely you'll end up with a low quality project (unless you're the best designer/coder in the world). In the second you will make everyone unhappy (developpers and users)... So my point is that if you want to succeed, think about forward compatibility from the start ! That's what we did with Matroska, and we managed to get some confidence from users. Even though the format is not finished and has larger potentials of evolution. This API we're talking about being a plugin API, it's even more important that you get developper acceptance/confidence. And that when you make a change all users don't have to rebuild their whole system. Even the 0.x version should be usable for developpers to start experimenting with it and give you precious feedback before you do proceed with version 1.0. > 1.1 - the main API [say some vtables] have changed [new methods added to > the end of tables]. All plugins should be rebuilt together with the > main library. dependant applications are still binary compatible with > the library. This is not needed at all to rebuild anything. At least the way I propose it. BTW there are 2 schools for version numbers. Some people release 1.0 when it is designed but not fully tested and release sub versions to have the real thing working. Some other release version 1.0 and never need to release something else (look at the Macromedia products). I'm more for the latter school. But that means that you can still work with version below 1.0 in a decent manner.