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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.