Re: [Freerdp-devel] FreeRDP Compression Library

[Brad H. <br...@fr...>]

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