From: Miguel F. <mi...@ce...> - 2003-11-11 22:18:02
|
Hi Michael, On Tue, 2003-11-11 at 13:33, Michael Roitzsch wrote: > I just think the two files xine.c and xine_interface.c could need some > cleanup, since at least I cannot see a convention which contains what. well, sort of. xine.c contains functions dealing with starting/stopping/seeking in general, while xine_interface.c is more like parameters setting and other public API glue. i agree that the separation is not completely clear, but it doesn't look that bad i think. > My idea would have been to move internal functions that clearly operate > on a specific struct as a function pointer into this struct. > > Examples? Ok: > * These could go into xine_stream_t: > xine_set_speed_internal() > xine_stop_internal() > xine_close_internal() > xine_open_internal() > xine_play_internal() these internal functions are already static, what's the gain of moving them to the struct? perhaps xine_set_speed_internal should be, in fact, an internal api function. given that some input plugins may change the speed it would be nice if they used a single function for that. > xine_get_current_position() > xine_get_current_info() > xine_get_stream_length() > * These could go into extra_info_t: > extra_info_reset() > extra_info_merge() > > The convention could then be: xine.c contains the implementations of the > struct member functions, similar to what all the other components like > metronom, decoders, output loops do; and xine_interface.c contains all > functions available in the public API. > > Helper functions for plugins should remain plain functions for the > reasons you gave. But moving the above functions (and maybe some more I > haven't found, but I guess these are the majority) into the structures > looks much cleaner (and more object-oriented) to me. more object-oriented, yes... cleaner, maybe... more troublesome? yes ;-) i think that these internal engine functions (which are not helper/internal api functions) are much more likely to change than our plugin api structs, for example. adding/removing functions or variables to xine_stream_t may get worse than it is now. imho, what we really need to set a cleaner and stable internal api (the one to be used by plugins - including external ones) is: - well defined internal api functions with standard prefix (done, thanks Thibaut and Daniel) - a very small set of "public" variables of xine_stream_t that can be used by plugins (such as xine, input_plugin, demux_plugin, metronom, video_out, video_fifo, audio_out, audio_fifo. did i missed anything?). these would be grouped at very start of the struct and guaranteed to not change during the stable series. - plugins would be _forbidden_ to access any other xine_stream_t member (they would be "private" ;-). everything else they need has to be provided by internal api functions. regards, Miguel |