I hope everyone agrees on the goals in this order:
1. free information and software
2. broad participation
3. cool features
> Since we've chosen a BSD style license for the client
> portion, I would think that straight C would be the best answer.
Hm? BSD license allows even for programming in elisp.. :-)
> adamant about using C++, then I would suggest using C++ without the STL
> internally, but still providing a C wrapper for the functionality of
> the library.
There is no doubt that a C library will yield broadest access.
C++ gives additional headaches regarding template instantiation,
linking with non C++ programs etc.
Under this aspect C is the choice.
On the other hand, we publish the protocoll and encoding standards,
so anyone is able to reimplement it, yes it might even be implemented
in Java, in case CD drives get their own IP numbers some day.
So people do not ultimately depend on our reference source, they depend
on the published standard.
Another issue is that at the moment we basically have to consider only
two compilers:
MSVC++ for the die hard Win32 crowd and gcc/egcs for all other systems.
(Note that I exclude the Mac, as I am not sure, what their environmnt
looks like)
If these compilers do not force a programmer to use C++ for their
client, in case they want to interface to a C++ lib, I would
say C++ is OK.
>From the problem side I doubt that our problem is so complicated
that we would really need C++.
So I would opt for playing safe and choosing C for the library.
> I believe Marc has started working on that.
Aye Sir. But I play charwoman right now, not star designer.
So feel free to post your killer specs here!
Bye,
Marc