From: Michael R. <mr...@us...> - 2003-11-15 14:39:23
|
Hi Miguel, > well, i really tried converting a couple of functions in xine.c to > use the two structs approach just to see how much work it would > take... i must say i didn't liked much the result. it seemed a bit > overkill for the sake of cleaning up internal interfaces. some > observations: > > - it would add a lot of castings from public struct to private one. > that is, stream = (xine_stream_internal_t *)stream_gen; in several > functions. I don't really consider this a problem. It's just some ten lines or so. > - some lines start having so many levels of indirection, it looks a > bit ridiculous imho... > stream->public_part.input_plugin->input_class->get_description(stream >->public_part.input_plugin->input_class->get_description); That's quite a good argument. > - moving variables between public and private sections requires a lot > of work (renaming variables, adding/removing prefixes all around). > this step will be needed for sure, unless all plugins are fixed at > the same time to not use public variables anymore. Another quite good argument. > so, if nothing else, the #ifdef idea might provide a migration path: > we could use it to cleanup the interface, hiding private data and > moving the remaining variables while we fix the plugins... Ok, so go with the #ifdef for now. I can complain again later. ;) > > One reason is that during my last engine modification > > (vo_frame->stream now allowed to be NULL), an idea crossed my mind > > that a very complex post plugin (whatever it might be doing) could > > actually implement its own xine_stream_t interface and have > > vo_frame->stream of the frames it emits point to this. Output layer > > could then access parts of this (metronom for example). This is > > just an idea, nothing substantial, but it would be more clear with > > separated public/private structs of xine_stream_t. > > a plugin providing it's own engine? sounds odd. besides, the plugin > would have to rewrite everything (video_out and audio_out for > example, since they are compiled to use the private elements of > xine_stream_t) > > definitely 2.0 material imho. Definitely. Was just an idea. Michael -- "Writing in C or C++ is like running a chain saw with all the safety guards removed." -Bob Gray |