On 2008/09/02 04:10, Eric Wong <[EMAIL PROTECTED]> wrote: > Max Kellermann <[EMAIL PROTECTED]> wrote: > > Start exporting the client struct as an opaque struct. For now, pass > > it only to processCommand() and processListOfCommands(), and provide a > > function to extract the socket handle. Later, we will propagate the > > pointer to all command implementations, and of course to > > client_print() etc. > > While I like most of the "client" series, this is one I'm not entirely > comfortable with. Opaque or not, I've never liked unnecessarily > exposing structs between unrelated modules. > > Instead, we can cache the linear lookup in fdprintf() and client_print() > for performance.
To make something handle a command, we have to pass something - your concept of global variables obviously won't fit here, because there may be more than one client. Currently, we pass the file descriptor. That's worse than passing an opaque struct, since the function makes assumptions on the nature of the file descriptor. A pointer to an opaque struct is just this - a pointer, and the function cannot do anything with it except using it for a well-defined client_XXX() API. Everything, including proper buffering and delayed writing will be hidden in the implementation. Why implement lookup algorithms for fd->pointer, when you can use the pointer in the first place? Max ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
