My suggestion is to split the functionality of LogMx' FileManager into two parts: The data retrival part and data decoding part.
For example I've written the file manager which can decode zip/gzip local files (see this post: viewtopic.php?f=2&t=248&p=548&hilit=gzip#p548). I still can't use it for reading gzipped files over scp/ftp/htp or other protocolls.
Every combination of protocoll and compression/encoding must be implemented in new Manager.
Concrete suggestion would be: split the protocol and raw data transmission into separate API, say ProtocolManager. Create another separate API for character decoding or decompression of binary data into input understandable by Parser (which are e.g. UTF-16 Strings). This might be called DecodingManager.
Splitting Data receving and decoding from LogMx Manager
Re: Splitting Data receving and decoding from LogMx Manager
Hello,
I agree that splitting Managers in "ProtocolManager" and "DecodingManager" will help you in this case. You would be able to have many different ProtocolManager that may transparently use the same "GZIPDecodingManager" for example.
Unfortunately, we really want to keep LogMX simple, and in my own opinion, i don't think that such a split will be useful in many cases except for compressed files. On the other hand, so many people are already lost to implement Parsers/Managers... We should keep in mind that many non-developers try to tune LogMX, including by writing Parsers/Managers.
Maybe the solution would be for us to add the support of zip/gzip for our built-in SCP/SFTP/HTTP managers? As for user-defined Managers, reading through a GZIPInputStream as you did should not cost that much. We will keep this idea in mind for future versions...
Thank you for posting here such a smart question
Xavier
I agree that splitting Managers in "ProtocolManager" and "DecodingManager" will help you in this case. You would be able to have many different ProtocolManager that may transparently use the same "GZIPDecodingManager" for example.
Unfortunately, we really want to keep LogMX simple, and in my own opinion, i don't think that such a split will be useful in many cases except for compressed files. On the other hand, so many people are already lost to implement Parsers/Managers... We should keep in mind that many non-developers try to tune LogMX, including by writing Parsers/Managers.
Maybe the solution would be for us to add the support of zip/gzip for our built-in SCP/SFTP/HTTP managers? As for user-defined Managers, reading through a GZIPInputStream as you did should not cost that much. We will keep this idea in mind for future versions...
Thank you for posting here such a smart question
Xavier