Hi, BETA6->BETA7 changes for plugins' users are small: * Georgi's fixes to Makefile.in; * INPUT->Input & OUTPUT->Output; * no more TRY_PLUGINS exported in ptbuildopts.h, hence: * the gm patch removes all #ifdef and #ifndef that use it; The main difference is there is now a no-plugins way: since I had to patch openh323 to use the PDeviceManager interface (it is mandatory to get sound devices!), it means pwlib must provide it unconditionally. And since I cannot write a manager and plugins for each and every platform that pwlib supports, I just wrote a plugins_dummy.cxx, that belongs to $(PWLIBDIR)/src/ptlib/common/, and should be compiled in when plugins are not enabled, on any platform: it just uses builtin drivers... This implementation has natural shortcomings: it can't load plugins (!), hence the part of the API about them is just return NULL (or FALSE, whatever applies); but apart from that, it can replace the real plugin manager, for apps that don't use fancy things. (ie: I compiled my pwlib without plugins, and launched the patched binary gm, as provided by dominance, and it just worked, looking as if plugins never existed). Let's try to explain why openh323 has to be patched: * for video, the app creates the PVideoInputDevice *, and handles it to openh323, that then doesn't care if it's plugins or builtins; * for sound, the app tells openh323 which device name it wants to use, and from that openh323 creates&opens a PSoundChannel, using builtins... This lack of symmetry is bad: if the pwlib provides plugins, then both the app&openh323 must use the same mean to access sound devices (ie: both PDeviceManager, or both the builtin PSoundChannel)... I don't think it is possible to make the situation symmetric without breaking the source-compatibility in apps, which the use of plugins does anyway, but in a quite small way (look at the size of the changes to gm). This is the inclusion path I foresee: * $(PWLIBDIR)/include/ptbuildopts.h.in gets an added .in, and a nice line is added to $(PWLIBDIR)/configure.in to reflect this (can be done _NOW!_); * the managers (dummy & dlopen) get added to pwlib (may wait a little: the API should be clean&nice), but only dummy is enabled by default; * openh323 gets patched; Here is the list of working configurations: * patched pwlib without plugins, with whatever configuration of patched/unpatched openh323&app: well, since the dummy PDeviceManager uses only built-in drivers, no surprise; * patched pwlib with plugins, unpatched openh323, unpatched app: since both the app&openh323 will use the built-ins, no problem; * patched pwlib with plugins, patched openh323, patched app: well, this is the ideal configuration, with all bells and whistles! Here is the list of configurations to avoid: * patched pwlib with plugins, unpatched openh323, patched app: sound will break, because the app will want "OSS /dev/dsp3.14" were openh323 would only accept "/dev/dsp3.14"; * patched pwlib with plugins, patched openh323, unpatched app: sound will break, because the unpatched app will get "/dev/dsp3.14" as a sound device were openh323 would only accept "OSS PiCam" (this one is annoying); Snark PS1: the name "I'm in a real hurry", is because I may not be able to take care of that much longer, perhaps not even until the end of the week... I would really need someone to take over real quick. I'll still be able to answer questions (with a delay), but probably not provide much more code. PS2: the oss plugin stems from the oss driver, that was supposed to work on *BSD too, and the dlopen implementation of the devices manager should run on any system providing dlopen&dlsym. Any BSD tester?
Attachment:
release-beta7.tar.bz2
Description: application/bzip