On Saturday 27 August 2011 05:04:24 Marc-André Moreau wrote: > One other thing which should have been moved out but hasn't been moved out > yet is bitmap decompression. Later, this will also become bitmap > compression, as the server part of FreeRDP gets expanded. And then we'll > get a couple more compression/decompression routines in, such as bulk > compression, and later maybe NSCodec as well. We also currently have the > color conversion code which sits in libfreerdp-gdi, but really is a > separate component. Its difficult to know exactly how to break these down, because we don't yet see how everything will be used. However I'd suggest fine grained on the headers, and coarse grained on the libs. There is a non-trivial cost on loading dynamic libraries (I vaguely recall a paper from the glibc guy that was featured on LWN, but it was a couple of years ago IIRC).
> What we could have though is a generic "compression library" where we put > all sorts of compressors/decompressors. Those compressors would be the > default ones used, but would be registered through callbacks to allow a > client or server to easily replace those components by their own. For > instance, one might want to develop hardware products that can be used as > replacement of those software components. That can actually make a lot of > sense of a thin client. In the case of a proxy, many > compressors/decompressors wouldn't even be used, since the proxy can relay > most of the stuff as-is without decompressing/recompressing. I guess this depends on the proxy purpose. It may want to inspect some things for logging or to provide "acceleration". So this is a tradeoff between the thin-client needs for minimal memory footprint and the proliferation of libraries / plugins. So if it isn't a lot of code, it can just get dumped into libfreerdp-common or libfreerdp-util (or whatever). If it is a lot of code, then it probably gets to be its own plugin / lib. > Does anybody have an idea for a name this library could have? I thought of > libfreerdp-compression, but it's quite a long name. How about libfreerdp-z? > It's a "compressed" name, I don't know, I'm in lack of inspiration right > now for a name. If there is a separate library, either seems OK to me. /usr/lib has some really long names already, and we don't normally type it, so I doubt it really matters that much :-) Brad ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
