Julian Scheel wrote: > Actually an even more interesting point are the concerns of Johannes of > adding too many details to the API. Actually my impression is that, as > said by others too, in the past every possible detail went into the API, > why should this be wrong now? > I can basically follow your concerns of having to remove parts of the > API later, but in this case we don't talk about "wrong" additions, but > about additions that might not be used in the end, because no > broadcaster uses them. Actually this wouldn't be a problem, as it only > would make sure that we would be aware of all possibilities and wouldn't > come into a situation where someone starts using a part of the spec > which we previously declared as not important. In the worst case it > could become a big problem adding those parts later on, because they > would break binary compatibility in a non-EXPERIMENTAL state. The point is that it is _easy_ to add definitions to a (well-designed) API but it is _hard_ to modify existing definitions later. A good API is both minimal and extensible. Imho there is no need to include all aspects of the specs now, but it should be possible to add them later. So let's start with a minimal API definition. Just my 2 cents. Oliver -- -------------------------------------------------------- VDR Remote Plugin available at http://www.escape-edv.de/endriss/vdr/ -------------------------------------------------------- _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
