Re: Message negociation

On Thu, Jan 08, 2004 at 10:08:26AM +0100, Steve Lhomme wrote:
> Artem Baguinski wrote:
> 
> >the vtables with NULLs for not-implemented "methods" will be even more
> >efficient, cause you request all callbacks at once ;)
> 
> Nop, that's not the same thing. If you request everything at once, that 
> means you know the order of things in the vtable, ie using a fixed 
> struct. Hopefully the impact of using a struct is less important than 
> "message" parameters. You can add new callbacks at the end. Hopefully we 
> will never have a system with 5000 callbacks/message :) (and even though 
> it can still be handled by mosts systems)
> 
> So I agree with the vtable requested on "init". Something that would 
> look like this :
> 
> typedef struct dialog_vtable {
> 	int (*callback1)(void);
> 	void (*callback2)(int);
> 	long (*callback3)(long, void *);
> 	....
> };
> 
> int get_your_vtable(dialog_vtable *table_to_fill, int size_of_this_table);
>
> Depending on the "size_of_this_table" you know when to stop filling the 
> structure (or fill it with NULL when you support less features).
> 
> As said before, the structure has to be updated at the end, *always*.

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. 

making sure the "3rd party plugins" and main library are intact is a
matter of packging. say, you're a debian/redhat maintainer of the binary
package[s] with the media access library. everytime you wanna release
new version of the main library - you have to rebuild binary packages of
all plugins as well. every separate plugin package will then list the
main api as its dependancy and installing them will obsolete the older
versions.

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.:

0.x - unstable api [the api is being designed, changed happen often as
  we go along. i won't recommend binary distribution at all]
1.0 - stable api and relatively stable implementation, the binary
  packages can be created starting from this version, but they only make
  sence if there are applications adopting the standard. i'd suggest to
  create a couple of reference applications while working on
  designing the library. this way you have the test cases immediatelly.
1.0.x - bugfixes / minor changes / optimizations in 1.0.x. the plugins
  remain binary compatible with the 1.0, only the main library has to be
  rebuilt
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. 
1.1.x - bugfixes etc for 1.1
..

2.0 - the working group has discovered some major design flaws in the
  api or has come up with some new ideas never considered before and has
  redesigned it more seriously then before. Main library, plugins and
  applications has to be rebuilt or even modified to support the new
  version. This one shouldn't happen too often or the goal of the
  project will never be reached. But it's also inevitable i'm afraid. On
  systems allowing several versions of the library to peacefully coexist
  the old unmaintained applications may still be used with old version
  of the library / plugins. [compare with gtk-1.2 / gtk-2.0 situation].

-- 
gr{oe|ee}t{en|ings}
artm